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ABSTRACT 


The  mission  of  the  Naval  Postgraduate  School  (NPS)  is  to  educate,  train  and 
prepare  officers  for  the  21st  Century  Navy  (Austin,  1988).  Distance  learning,  also 
known  as  distance  education,  remote  learning  or  video  teletraining,  is  defined  as 
communication  between  an  instructor  and  student  via  some  form  of 
telecommunications.  Distance  learning  has  the  potential  to  enable  dramatic 
improvements  in  training  and  education  by  providing  remote  access  to  high-quality 
presentations.  There  is  also  a  potential  to  multiply  training  and  education  benefits,  and  to 

provide  savings  in  travel  and  lost  time  expenses. 

This  thesis  investigates  distance  learning  combined  with  a  new  technology 

known  as  the  Multicast  Backbone  (MBone).  It  documents  how  Dr.  Richard 
Hamming’s  course  “Learning  to  Learn”  was  transmitted  world- wide  over  the 
Internet’s  Multicast  Backbone  (MBone)  for  an  entire  quarter. 

This  thesis  proves  that  the  MBone  is  an  economically  feasible  approach  that 
works.  This  is  the  first  documented  attempt  to  provide  complete  course  coverage 
with  world-wide  scope  for  a  full  academic  quarter  usmg  the  MBone.  Specific 
lessons  learned  are  included  in  an  MBone  user’s  guide  and  recommendations  for 
future. 
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I.  INTRODUCTION 


This  thesis  investigates  various  aspects  of  distance  learning  combined  with  a  new 
Internet  technology  known  as  the  Multicast  Backbone  (MBone).  The  research  revolves 
aroimd  a  case  study  that  documents  the  learning  points  derived  from  a  successfril 
worldwide  Multicast  of  Dr.  Richard  Hamming’s  course  “Learning  to  Learn.”  This  is  the 
first  documented  attempt  to  provide  complete  course  coverage  for  a  full  academic  quarter 
using  the  MBone. 

A.  BACKGROUND 

1.  Distance  Learning 

Distance  learning,  also  known  as  distance  education,  remote  learning  or 

videoteletraining,  is  defined  as  communication  between  an  instructor  and  student  via  some 

form  of  telecommunications.  It  utilizes  technology  for  teaching  and  learning  situations  in 

which  students  are  geographically  separated  from  educators,  and  both  depend  on 

electronic  devices  to  communicate  (Biggs  94).  A  draft  Military  Standard  on  the 

“Interoperability  and  Performance  Standard  for  Video  Teleconferencing”  defines  video 

teleconferencing  (VTC)  and  video  teletraining  (VTT)  as  follows: 

Video  teleconferencing  is  a  two-way  electronic  form  of  conununications 
that  permits  two  or  more  people  in  different  locations  to  engage  in  face-to- 
face  audio  and  visual  communication.  Meetings,  seminars,  and  conferences 
are  conducted  as  if  all  participants  are  in  the  same  room.  Video  teletraining 
(or  distance  learning)  is  the  use  of  teleconferencing  point-to-point  or  multi¬ 
point  to  provide  interactive  remote  site  training.  (MIL-STD- 188-33 1,  93) 

Distance  learning  is  the  subject  of  much  speculation.  The  Office  of  Naval 
Technology  has  conducted  research  in  the  field  of  distance  learning  with  the  goal  of 
finding  more  cost-effective  ways  to  train  personnel  who  are  geographically  remote  from 
training  resources  (Sinq)son,  Pugh  91).  In  1991,  the  Office  ofNaval  Technology 
sponsored  a  six-month  study  involving  743  Navy  students  to  investigate  the  effectiveness 
and  user  acceptance  of  live  instruction  (Sin:q)son,  Pugh  91).  This  study  used 
videoteletraining  technologies  to  deliver  lecture-based  training,  with  the  overall  goal  of 
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exploring  technologically  cost-effective  ways  to  train  personnel  who  are  geo^aphically 
separated  from  training  resources. 

This  goal  was  reached  by  conducting  an  empirical  study  corrqjaring  traming 
effectiveness  and  user  acceptance  of  live  instruction  and  six  different  alternative  VTT 
technologies:  multichannel  two-way  video  with  two-way  audio,  single  channel  two-way 
video  with  two-way  audio,  one-way  video  with  two-way  audio,  one-way  video  with  one¬ 
way  audio,  one-way  video  with  intermittent  two-way  audio,  and  audiographics  (Sm^ison, 
Pugh  91). 

This  study  showed  that  several  different  forms  of  VTT  technologies  were  effective, 
in  terms  of  both  student  performance  and  student  and  instructor  acceptance.  The  specific 
type  of  VTT  technology  did  influence  student  performance  and  attitudes,  but  had  a  far 
smaller  effect  than  student  experience.  The  study  also  noted  that  the  most  successfril  VTT 
technologies  were  those  allowing  continuous  two-way  audio  with  either  two-way  or  one¬ 
way  video.  And  finally,  student  test  performance  was  poorer  with  VTT  systems  that 
restricted  remote  students’  ability  to  converse  with  or  see  the  instructor  (Simpson,  Pugh 
91). 

One  recommendation  resulting  from  the  project  was  that  the  Chief  of  Naval 
Education  and  Training  (CNET)  continue  efforts  to  refine  the  CNET  VTT  network,  as 
well  as  analyze  the  feasibility  and  cost-effectiveness  of  extending  the  architecture  of  the 
CNET  VTT  network,  using  VTT  technologies  such  as  one-way  video  with  two-way  audio 
and  one-way  video  with  one-way  audio  (Simpson,  Pu^  91). 

Taking  VTT  one  step  further,  in  1992  the  Office  of  Naval  Technology  sponsored 
another  study  to  determine  if  VTT  could  be  used  to  deliver  hands-on  training,  as  well 
(Simpson,  Pugh  92).  Up  to  this  point,  VTT  had  been  used  for  lecture-based  training  only. 
The  results  of  this  project  showed  that  VTT  was  effective  for  lecture,  discussion,  and 
hands-on  demonstration  portions  of  training,  as  indicated  by  the  final  examination,  student 
course  evaluations,  and  observations.  The  VTT  classroom  design  was  also  effective  for 
hands-on  training  It  could  serve  as  a  model  for  others  designing  VTT  classrooms  for 
hands-on  training. 


2 


More  recently,  in  1993,  the  Navy  Personnel  and  Research  Development  Center 
documented  procedures  for  converting  live  instruction  for  VTT  delivery.  The  intent  was 
to  make  these  procedures  available  to  Navy  trainers  and  others  responsible  for  VTT 
delivery  (Simpson  93). 

The  studies  sponsored  by  the  Office  of  Naval  Technology  and  performed  by  the 
Navy  Personnel  Research  and  Development  Center  have  all  proven  that  VTT  can  be  used 
to  link  students  and  instructor  across  great  distances.  There  are  alternative  VTT 
technologies  that  vary  greatly  in  cost,  so  the  Navy  must  focus  on  selecting  the  proper  and 
most  cost-effective  VTT  technologies. 

2.  Multicast  Backbone  (MBone) 

The  Multicast  Backbone  (MBone)  originated  from  experiments  during  the  1992 
Internet  Engineering  Task  Force  (IETF)  conferences  in  San  Diego  and  Boston,  in  which 
live  audio  and  video  were  transmitted  around  the  world.  The  MBone  ciurently  links  Unix 
workstations  and  has  been  called  a  ‘virtual  network’  because  it  uses  the  physical  Internet 
to  support  routing  of  Internet  Protocol  (IP)  multicast  packets  (Casner  93).  Multicasting  is 
a  frmction  that  allows  conservation  of  network  traffic  because  a  sending  site  can  ship 
audio  and  video  packet  streams  that  are  replicated  only  once,  even  though  receiving 
routers  distribute  the  videoconference  to  multiple  desktops  (Wexler  93).  For  example,  on 
a  multicast  network,  a  packet  sent  from  machine  A  can  be  distributed  to  machines  B,  C, 
and  D  without  the  original  packet  having  to  be  sent  three  times  (Weiss  95). 

Because  a  standard  audio  transmission  uses  about  64  Kilobits  per  second  (Kbps), 
and  a  default  video  transmission  takes  approximately  128  Kbps,  an  average  worldwide 
conference  will  take  up  to  about  200  Kbps  of  bandwidth  and  could  even  go  as  high  as  the 
global  limit  of  500  Kbps.  This  is  nearly  one-third  of  a  T1  line,  which  is  1.5  Megabits  per 
second  (Mbps)  and  is  a  common  site-to-site  link  on  the  Internet  today.  Without  the 
benefit  of  multicast,  that  T1  line  can  be  completely  utilized  by  just  three  conferencing 
sessions,  not  even  taking  into  account  other  network  uses  such  as  electronic  mail,  file 
transfer  and  Web  browsing.  Multicast  represents  a  huge  savings  when  one  considers  the 
amount  of  bandwidth  that  is  consumed  by  audio  and  video. 
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B.  MOTIVATION 


1.  What  is  the  Importance  of  Distance  Learning? 

Any  organization,  (private  industry,  Government  or  mihtary)  faced  with  increasing 
costs  and  decreasing  resources  tends  to  push  education  and  traming  down  the  priority  list. 
Training  programs  may  be  eliminated.  Educational  institutions  might  even  be  forced  to 
limit  what  is  offered  to  students.  In  the  United  States  today,  many  organizations  are 
forced  to  do  more  with  less.  When  it  comes  to  education  and  traming,  distance  learning 
provides  an  option  that  is  economically  attractive  for  accomplishing  educational 
requirements. 

The  Navy  possesses  a  wide  geographic  dispersal  of  home  ports,  fleet  units,  and 
Navy  Reserve  detachments.  The  costs  associated  with  transporting  Navy  personnel  to  a 
few  facilities  for  classroom  training  are  great.  These  costs  include  transportation,  travel 
expenses,  and  the  travel  time  lost  from  duty.  In  q)ite  of  these  factors,  there  is  stiU  a 
requirement  to  train  Navy  personnel  who  are  geographically  remote  from  traming 
resources  (Sin^son,  Pugh  92).  Effective  training  of  personnel  is  essential  to  achieve  and 
maintain  national  security,  as  well  as  national  strategic  objectives. 

Issues  that  have  a  negative  effect  on  the  ability  of  the  Department  of  Defense 
(DoD)  to  acconq)lish  that  mission  are  personnel  drawdowns,  base  closures,  and  reduced 
budgets.  Effective  training  of  personnel  is  essential.  In  fiscal  year  1994,  DoD  allocated 
about  $15  billion  towards  individual  training  and  education  (Biggs  94).  Because  the 
drawdowns  have  made  it  increasingly  difficult  to  offer  service  members  the  opportunity  to 
go  on  TAD,  distance  learning  provides  an  economical  and  efficient  solution.  By  importing 
an  instructor  via  some  form  of  telecommunication,  a  command  can  save  on  travel  dollars 
per  diem  and,  in  most  cases,  registration  fees. 

In  the  NaVy,  at  a  time  when  deployment  schedules  have  become  restrictive, 
distance  learning  allows  for  increased  flexibility  for  leaders.  With  online  course  work,  the 
Navy  can  offer  classes  at  any  time  of  day.  As  more  ships,  commands,  and  individual  units 
become  connected  to  local-area  networks  (LANs)  and  wdde-area  networks  (WANs), 
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distance  learning  programs  can  be  implemented,  providing  more  economical  avenues  for 
training. 

Does  distance  learning  work?  A  variety  of  videoconferencing  and  distance 
learning  technologies  have  received  considerable  attention  in  the  DoD.  Those  studies 
previously  mentioned  all  reached  the  same  conclusion  and  made  the  same 
recommendation.  That  is,  VTT  in  several  different  forms  was  effective  in  terms  of  both 
student  performance  and  student  and  instructor  acceptance.  The  studies  also  agree  that 
the  Chief  of  Naval  Education  and  Training  should  support  the  use  and  continued  study  of 
VTT  for  educating  Naval  personnel  (Simpson,  Pugh  91). 

Due  to  the  fact  that  training  needs  for  each  military  branch  are  different,  difhculty 
arises  when  trying  to  plan,  prepare  and  inclement  training.  Understanding  when  an 
approach  can  and  ought  to  be  employed  and  what  benefits  will  be  received  is  crucial  for 
successful  in^lementation.  The  following  scenarios  are  provided  as  a  means  of 
determining  when  distance  learning  technologies  may  be  appropriate  (Wright  93) ; 

Population  is  dispersed  and  cannot  be  economically  transported  to  a  central 
training  site. 

Students  in  a  training  group  have  diverse  learning  styles,  skills,  or  proficiency. 

Delivery  must  be  closely  monitored  for  accuracy  or  interpretation. 

Students  cannot  be  taken  from  job  for  extended  periods  due  to  mission 
requirements. 

Live  training  is  cost  prohibitive. 

The  number  of  instructors  with  proper  credentials  is  limited. 

The  Naval  Postgraduate  School  (NPS)  has  several  requirements  and  objectives  in 
the  area  of  distance  learning.  Off-campus  education,  technology  refresher  training  of  NPS 
graduates,  and  the  abihty  to  ‘import’  an  instructor  without  the  travel  costs  are  some  of 
these  requirements  (Steckler,  Stewart  94). 
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2.  Why  use  the  MBone? 

The  MBone  is  a  part  of  the  Internet  that  is  used  for  audio  and  video 
teleconferencing.  It  is  attractive  in  that  it  works  and  provides  real  value  today.  The 
MBone  can  bring  expertise  over  long  distances  and  multiply  training  benefits.  The 
development  of  the  Internet  has  expanded  the  walls  of  the  traditional  classroom.  Students 
today  have  access  to  a  wealth  of  global  information,  such  as  remote  Ubraries,  discussion 
groups,  and  computer  conferences.  Students  also  can  make  connections  with  other 
students  and  with  teachers  around  the  world  (Aoki,  Goto  95). 

The  combination  of  MBone  resources  with  the  concept  of  distance  learning 
provides  students  and  teachers  with  the  capability  of  physically  seeing  and  talking  to  each 
other.  Just  imagine  the  value  of  live  video  brought  directly  fi'om  the  space  shuttle  into 
the  classroom.  Think  about  watching  scientists  study  the  ocean  floor  in  the  Monterey  Bay 
and  then  being  able  to  ask  them  questions  directly,  all  via  a  computer.  These  capabilities 
are  currently  available. 

Another  expected  benefit  of  using  the  MBone  is  be  the  ability  to  archive  audio  and 
video  on  the  Internet  for  digital  video  retrieval  on  demand.  This  future  work  will  literally 
put  educators  and  their  lectures  online  and  open  up  even  more  possibilities  for  distance 
learning.  It  will  actually  bring  the  classroom  to  the  student  anytime  it  is  necessary.  This  is 
an  extremely  promising  area  for  future  work. 

C.  THESIS  SUMMARY 

This  thesis  is  broken  into  the  following  chapters.  Chapter  n  discusses  related 
work  in  the  fields  of  distance  learning  and  the  MBone.  Chapter  III  provides  the  reader 
with  an  understanding  of  the  MBone.  Chapter  IV  describes  the  principal  problems 
investigated  in  this  thesis.  Chapter  V  dociunents  the  distance  learning  case  study  involving 
the  multicast  of  Dr.  Hamming’s  class.  Chapter  VI  summarizes  the  conclusions  drawn 
fi'om  the  case  study,  as  well  as  recommendations  for  future  work.  In  addition,  several 
appendices  are  provided  as  supplements  to  the  thesis.  Appendix  A  is  a  User’s  Guide  for 
accessing  and  using  the  MBone  tools.  Appendbc  B  is  a  list  of  acronyms  used  throughout 
this  thesis.  Appendix  C  is  a  glossary  of  terms  used  in  this  thesis. 
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n.  RELATED  WORK 


A.  INTRODUCTION 

This  chapter  discusses  recent  work  that  has  been  conducted  in  the  fields  of 
distance  learning,  the  multicast  backbone,  and  network  connectivity  for  educational 
purposes.  A  short  summary  of  each  study  is  provided  to  explain  the  study's  topic  and  how 
it  relates  to  this  thesis. 

B.  GAMBRINO;  MBONE  USABILITY 

This  thesis  looks  at  the  choices  managers  face  v^dien  dealing  with  video 
teleconferencing  (Gambrino  94).  In  particular,  this  theas  focuses  on  the  perceived 
effectiveness  of  the  MBone  fi’om  a  manager’s  perspective.  Data  for  this  research  is  based 
on  an  NPS  study  with  the  Monterey  Bay  Aquarium  Research  Institute’s  (MBARI)  Internet 
conference  experiment  to  conq)are  the  MBone  versus  face-to-face  viewer  perceptions  of 
the  different  communication  media.  This  study  concluded  that  the  MBone  should  not  be 
used  in  commimication  situations  involving  emotional  conflict,  bargaining,  and 
negotiation.  The  MBone  is  recommended  for  use  in  communication  situations  involving 
uncertainty  reduction. 

C.  MICE  PROJECT:  VIDEO  ARCHIVING  IN  EUROPE 

Hie  Multimedia  Integrated  Conferencing  for  Europe  (MICE)  project  has  been 
piloting  MBone  technology  in  Europe.  In  order  to  make  the  Hamming  lecture  series 
accessible  to  the  much  wider  audience  in  Emope,  the  author  provided  copies  of  the  lecture 
series  video  tapes  to  the  major  MICE  National  Support  Centers  in  Europe,  which  then 
arranged  for  a  remulticast  of  the  Hamming  lectures.  A  further  research  endeavor  includes 
digitizing  video  for  media  retrieval  on  demand.  More  information  about  the  MICE  center 
can  found  at  http://www.cs.ucl.ac.uk/mice/mice.html  (Handley) 

D.  BIGELOW:  INTERNETWORKING  K-1 2  SCHOOLS 

This  thesis  documents  the  planning,  design,  and  implementation  of  a  regional,  wide 
area  network  connecting  K-12  schools,  research  institutions,  libraries,  and  institutions  of 
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higher  education  throughout  the  Monterey  Bay  area  of  California  s  central  coast.  It  can 
be  found  online  at  http://www.stLnps.fKivy.mil/~rjbigelo/thesis.html  (Bigelow  95). 

E.  STECKLER  AND  STEWART;  DISTANCE  LEARNING  PLAN 
The  study  examined  requirements  and  design  for  the  development  and 

implementation  of  a  videoteletraining  (VTT)  system  for  25  Defense  Finance  and 
Accounting  Service  (DFAS)  centers.  The  study  focuses  on  basic  and  technological  issues 
regarding  all  aspects  of  VTT  as  they  apply  to  DoD,  including  current  technology,  evolving 
VTT  hardware  and  software  capabilities,  and  compression  algorithm  standards  (Steckler, 
Stewart  94). 

F.  RETTINGER;  DESKTOP  VIDEO  CONFERENCING 

This  study  looks  at  the  various  aspects  of  desktop  video  conferencing.  This 
research  involves  an  experiment  that  utilizes  the  technology  of  the  MBone  to  deliver  a 
week-long  seminar  to  participants  throughout  North  Carolina.  Topics  also  include  the 
human  factors  issues  with  desktop  videoconferencing  and  the  interactive  seminar 
demonstration  (Rettinger  95). 

G.  DISTANCE  LEARNING  EFFORTS 

As  the  hitemet  connects  universities  and  colleges  all  over  the  world,  educational 
applications  are  widely  discussed  among  educators  and  researchers.  The  biggest 
advantage  of  the  Internet  is  its  international  connectivity  (Aoki,  Goto  95).  Regionally, 
there  is  a  research  project  called  Monterey  BayNet  which  has  been  internetworking  K-12 
schools,  colleges,  universities,  museums,  Ubraries,  government  agencies,  and  research 
institutions  in  two  California  counties  (Brutzman  95).  The  network  design  provides 
access  to  live  or  archived  media  using  a  variety  of  bandwidth  rates  (Brutzman  95).  This 
ongoing  network  project  gives  teachers  and  students  full  access  to  the  Internet  and  all  the 
information  that  the  World-Wide  Web  (WWW)  has  to  offer. 

H.  SIGGRAPH  ‘95  “MBone  UNPLUGGED” 

At  a  week-long  graphics  conference  held  at  the  Los  Angeles  Convention  Center,  a 
team  of  NPS  students  (including  this  author)  designed  and  built  a  mobile  MBone  cart  that 
used  wireless  networking  technology  in  order  to  broadcast  the  events  at  SIGGRAPH. 
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This  experiment  provided  a  more  in-depth  look  into  the  details  of  setting  up  a  network 
that  involves  MBone  transmissions.  It  gave  the  team  an  opportunity  to  test  the  limits  of 
wireless  communications  and  raised  a  series  of  questions  that  have  the  potential  to  further 
the  research  and  technology  of  the  MBone  (Brutzman,  Emswiler  95). 
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ra.  MULTICAST  BACKBONE  (MBone) 

A.  INTRODUCTION 

Over  the  last  decade,  the  personal  computer  (PC)  has  evolved  from  a  stand-alone 
personal  productivity  device  to  a  widely-connected  information  tool.  Networked  PCs  are 
becoming  the  center  of  business  commimication.  PCs  are  already  used  to  send  faxes  and 
electronic  mail  (e-mail),  to  share  databases  and  automate  workflow,  and  even  to  hold 
long-distance  meetings  using  unicast  videoconferencing  tools.  The  resulting  boon  to 
productivity  is  spurring  strong  demand  for  further  PC-based  commimication  applications. 
The  drive  to  improve  communication  via  PC  is  a  major  force  behind  technology 
developments  in  the  1990s.  We  expect  that  eventual  availability  of  MBone  tools  will  be  a 
major  event  in  PC  evolution. 

The  author  has  read  articles  that  state  the  Multicast  Backbone  (MBone)  is  “not  yet 
ready  for  prime  time,”  and  has  attended  the  Internet  World  conference,  where  a 
multimedia  expert  stated  the  MBone  could  not  be  used  for  distance  learning.  As  a 
member  of  the  NPS  Information  Infrastructure  Research  Group  (DKG),  the  author  studied 
and  documented  the  viability  and  impact  of  distance  learning  over  the  MBone.  The  goal 
of  this  work  is  to  show  that  the  MBone  can  be  used  for  academically  useful  distance 
learning.  Some  technical  considerations  must  be  explained  first. 

The  MBone  provides  many-to-many  network  delivery  services  for  applications 
such  as  videoconferencing  and  audio  where  several  hosts  need  to  communicate 
simultaneously.  Because  the  MBone  utilizes  the  Internet,  there  are  no  enforced 
restrictions  on  its  use.  Although  this  capability  is  inqrressive,  it  does  have  drawbacks.  For 
example,  individuals  with  inadequate  equipment  or  improper  training  can  bring  down 
entire  networks.  If  the  MBone  is  to  be  considered  a  shared  medium  for  distance  learning, 
there  must  be  an  understanding  as  to  the  inqiacts  and  implications  of  doing  so.  This  work 
demonstrates  that  effective  global  learning  using  the  MBone  is  feasible. 

Multicasting  has  existed  for  several  years  on  local  area  networks  such  as  Ethernet 
and  Fiber  Distributed  Data  Interface  (FDDI).  However,  with  IP  multicast  addressing  at 
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the  network  layer,  group  communication  can  be  established  across  the  Internet 
(Macedonia,  Brutzman  94).  Because  multicasting  functionality  has  not  been  integrated 
into  many  routers,  the  MBone  is  layered  over  the  Internet  using  multicast  routers  (called 
mrouters),  which  typically  are  dedicated  workstation-class  machines. 

The  MBone  provides  near-real-time  audio  and  video  delivery.  Some  time  delays 
or  communication  failures  can  be  expected  because  of  network  congestion.  Packets  of 
data  that  carry  the  audio  and  video  signals  across  the  network  may  become  lost  during 
transmission,  causing  communication  dropout.  These  losses  are  a  function  of  overall 
Internet  capacity  and  are  largely  independent  of  the  number  of  people  subscribing  to  a 
given  MBone  session. 

B.  CONSIDERATIONS 

1.  Setting  up  an  MBone  Environment 

The  MBone  has  been  called  a  virtual  network  because  it  shares  the  same  physical 
medium  as  the  Internet.  It  uses  a  “tunneling”  scheme  to  forward  multicast  packets  among 
the  islands  of  MBone  subnets  through  Internet  IP  routers  that  (typically)  do  not  support 
IP  multicast  (Macedonia,  Brutzman  94). 

To  receive  multicast  packets  on  a  LAN,  a  system  administrator  will  need  to 
configure  an  mrouter.  This  can  be  either  a  single  workstation  on  a  LAN,  or  a  host 
dedicated  as  a  parallel  mrouter  (Macedonia,  Brutzman  94).  Another  option  is  to  take  an 
old,  unused  workstation  and  reconfigure  it  as  an  mrouter.  This  process  requires  adding  a 
second  Ethernet  card  to  the  workstation  so  that  this  mrouter  can  act  independently  and  in 
parallel  with  the  standard  IP  router  (Macedonia,  Brutzman  94).  The  Naval  Postgraduate 
School  uses  both  approaches.  Downloading  the  application  software  tools  is  the  next 
step. 

This  discussion  about  connecting  a  site  to  the  MBone  has  been  brief  For  a 
complete  set  of  instructions,  the  reader  should  look  at  the  Frequently  Asked  Questions 
(FAQ).  The  MBone  FAQ  is  a  good  source  for  system  administrators  wishing  to  establish 
an  mrouter  on  site.  It  provides  detailed  information  and  instmctions  for  downloading 
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software  tools  and  for  ensuring  that  multicast-compatible  kernels  are  available  for  target 
workstations.  The  FAQ  can  be  found  online  at  ftp://venera.isi.edu/MBone/faq.txt. 

2.  What  is  Needed  to  Participate  on  the  MBone? 

a.  Hardware  Requirements 

No  special  hardware  is  required  to  receive  video  on  the  MBone.  Decoding 
and  display  are  all  done  in  software  using  an  X-window  display.  The  data  rate  is  typically 
25  Kbps  to  128  Kbps.  Transmitting  video  requires  a  workstation  with  a  fi-ame-capture 
board  and  camera,  typically  a  camcorder  with  a  video  output  or  built-in  camera.  Several 
different  boards  are  supported,  including  Sun's  SunVideo,  SGFs  Indigo  Video,  and  the 
Sony  NEWS  frame  capture  hoard. 

To  receive  audio,  a  machine  must  be  audio  equipped  such  as  the 
SunSparclO  with  an  audio  box,  some  Hewlett-Packard  workstations,  the  SGI  Indy  and 
SGI  Indigo.  On  most  architectures,  no  hardware  other  than  a  microphone  is  required  - 
soimd  FO  is  via  the  built-in  audio  hardware. 

b.  Software  Requirements 

Software  applications  for  use  on  the  MBone  have  been  developed  by 
researchers  on  a  volimtary  basis.  At  this  time  the  tools  are  free  of  charge  and  need  only  be 
downloaded  and  placed  on  a  Unix  workstation. 

c.  Other  Requirements 

(1)  Good  lighting;  A  desk  lamp  is  significantly  better  than  ofiftce  lighting 
for  improving  image  quality,  especially  in  otherwise  low  light  conditions  with  inexpensive 
cameras. 

(2)  Video  camera:  If  video  is  to  be  transmitted,  a  fixed  focus  camera  that 
works  well  in  well  lit  conditions  is  fine  for  the  desktop.  A  video  camera  is  more 
expensive,  but  performs  better  in  lower  Ught  and  has  zoom  capability.  A  camera  is  not 
required  to  receive  or  display  video. 

d.  Associated  Costs 

Taking  time  to  leam  how  to  connect  to  and  use  the  MBone  is  what  usually 
poses  the  greatest  cost.  It  takes  approximately  one  to  three  weeks  for  a 
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network-knowledgeable  person,  working  part-time,  to  establish  the  MBone  at  a  new  site 
(Macedonia,  Bnitzman  94).  Depending  on  the  number  of  users  and  the  amount  of  MBone 
usage,  there  may  also  be  a  need  for  a  dedicated  MBone  network  admimstrator. 

Equipment  cost  is  often  relatively  low.  An  SGI  entry-level  workstation 
runs  between  $15-$20K.  The  cost  of  video  cameras  ranges  from  $50  for  a  suuple  desktop 
version  to  $2,000  for  a  high-powered  piece  of  equipment.  The  MBone  mailing  li^s 
publish  up-to-date  price  listings  on  the  latest  equipment  needed  for  commumcating  on  the 
MBone. 

Another  equipment  cost  that  must  be  considered  is  bandwidth.  NFS  runs 
the  MBone  tools  on  workstations  connected  via  Ethernet  (10  Mbps).  The  off-canqius 
links  are  via  T1  lines  (1.5  Mbps).  NPS  researchers  have  found  that  bandwidth  capacities 
lower  than  T1  are  generally  unsuitable  for  MBone  video  (Macedonia,  Bnitzman  94). 

Some  users  on  specially  configured  networks  have  managed  to  make  the  tools  work  at  56 
and  64  Kbps  (Macedonia,  Bnitzman  94). 

3.  Using  the  MBone  Tools 

The  following  is  a  list  of  MBone  applications  available  on  the  Unix  workstations 
at  the  Naval  Postgraduate  School.  Appendix  A  provides  detailed  instructions  for  using 
these  tools. 

(1)  Sftssinn  Directory  (sd):  Session  Directory  is  the  tool  used  to  manage 
MBone  sessions.  It  displays  available  sessions  and  can  be  used  to  create  new  ones. 
Sessions  will  be  announced  in  the  session  directory  window.  Clicking  on  a  session  name 
gives  information  about  the  session,  such  as  time  and  date  of  transmission. 

(2)  Network  Video  (uvi  tool:  Network  Video  is  used  to  transmit  and 
receive  slow-frame-rate  video.  It  has  a  default  bandwidth  of  128  Kbps,  which  provides  a 
typical  frame  rate  of  three  to  five  frames  per  second.  When  a  session  that  involves  video 
communications  is  selected  from  the  session  directory,  a  control  panel  appears.  The  panel 
consists  of  a  menu  bar,  a  box  to  show  iconic  versions  of  active  video  streams,  and  some 
number  of  additional  panels,  nv  allows  the  user  to  specify  various  options.  In  most  cases, 
the  assigned  defaults  are  adequate. 
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(3)  Visual  Audio  Tool  (vat^  version  2.4:  Visual  Audio  Tool  is  used  for 
audio  teleconferences.  When  a  session  that  involves  audio  communications  is  selected 
from  the  session  directory,  the  vat  window  appears.  It  is  not  necessary  to  speak  in  order 
to  participate  in  a  conference.  In  fact,  the  normal  etiquette  is  to  wait  until  the  speaker  has 
finished  and  has  opened  questions  to  the  floor  or  to  the  Internet,  before  speaking.  Using 
vat  requires  a  certain  amount  of  prudence  to  avoid  accidental  transmissions  during 
conference  sessions. 

(4)  Video  Conference  (vie):  Video  Conference  is  an  experimental  video 
conferencing  tool  for  transmitting  video  over  an  IP  Multicast  network.  The  main  vie 
window  provides  an  abbreviated  summary  of  all  sources  that  are  actively  transmitting 
video  to  the  conference  address.  If  no  one  is  transmitting  video  to  the  session,  the  text 
“No  Network  Sources”  is  displayed  in  the  window. 

(5)  Shared  whiteboard  (wb)  tool:  Shared  whiteboard  can  be  used  as  a 
^ared  white  board  drawing  surface  and  it  can  be  used  to  export  and  view  postscript  files. 
Speakers  can  make  their  sUdes  available  as  postscript  files  during  a  conference  session. 

The  camera  can  be  directed  at  the  speaker  while  the  slides  are  viewed  via  the  whiteboard 
facility. 

C.  SUMMARY 

It  isn’t  every  day  that  someone  says  to  you,  “Here  is  a  multimedia  television 
station  that  you  can  use  to  broadcast  from  your  desktop  to  the  world”  (Macedonia, 
Brutzman  94).  The  MBone  has  changed  the  way  people  work  and  interact  on  the  net. 

Today  the  MBone  is  used  by  thousands  of  researchers  in  collaborative  efforts  to 
fiuther  technology  and  other  research  efforts.  Created  in  1992  for  group  communications 
among  universities  and  research  labs,  the  MBone  has  approximately  1,800  nodes,  roughly 
the  same  number  that  the  Internet  had  in  1990. 

Many  events  are  broadcast  over  the  MBone,  including  NASA  Select’s  coverage  of 
shuttle  missions  and  audio  sessions  of  the  House  and  Senate.  The  November  18,  1994 
Rolling  Stones  concert  was  one  the  largest  MBone  events.  There  is  even  a  “radio- station” 
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called  Radio  Free  Vat,  where  any  MBone  participant  can  sign  up  for  spots  to  play  music 
“on  the  air.” 

It  is  the  author’s  opinion  that  the  most  significant  of  aU  uses  of  the  MBone  is  the 
ability  to  provide  distance  learning.  There  is  a  potential  to  multiply  traming  and  education 
benefits,  and  to  provide  savings  in  travel  and  lost  time  expenses.  More  important,  the 
MBone  is  a  convenient,  accessible  way  to  educate  personnel  all  over  the  world. 
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IV.  PROBLEM  STATEMENT 


A.  INTRODUCTION 

The  focus  of  this  thesis  is  to  investigate  what  is  required  to  produce  an  ongoing 
educational  event  over  the  Multicast  Backbone  (MB  one).  The  MB  one  is  a  new 
technology,  however,  several  questions  pertain.  Can  the  MBone  sustain  the  bandwidth 
constraints  and  imcertainties  associated  with  the  Internet?  Can  the  MBone  be  used  for 
distance  learning?  If  so,  how  is  it  done? 

When  transmitting  audio  and  video,  it  is  important  to  achieve  near-real-time 
quality.  This  quality  is  difficult  to  achieve  due  to  the  high  amount  of  bandwidth  associated 
with  the  two.  Private  networks  use  high-speed  dedicated  links,  whereas  the  Internet  is  a 
^ared  internetwork  with  many  thousands  of  users  doing  many  different  things  at  any 
given  time  (Muirden  95).  Today,  there  are  over  forty  commercial  products  for  conducting 
real-time  audio  and  video  over  the  Internet.  Two  of  the  most  widely  used  systems  are  the 
MBone  tools  and  CU-SeeMe  (Muirden  95). 

B.  NAVAL  POSTGRADUATE  SCHOOL  (NPS)  GOALS 

The  following  mission  statement  is  from  the  Naval  Postgraduate  School’s  World 
Wide  Web  home  page. 

The  mission  of  the  Naval  Postgraduate  School  is  to  enhance  the  seciuity  of 
the  United  States  of  America  through  graduate  and  professional  education 
programs  focusing  on  the  unique  needs  of  the  military  officer.  These 
programs  are  sustained  by  research  and  advanced  studies  directed  towards 
the  needs  of  the  Navy  and  DoD.  Our  goals  are  to  increase  the  combat 
effectiveness  of  the  armed  forces  of  the  U.S.  and  its  allies,  and  to 
contribute  to  fundamental  scientific,  engineering,  policy,  and  operational 
advances  that  support  the  Navy,  DoD,  and  other  national  security 
establishments  (Taylor  95). 

NPS  has  a  vision  of  being  the  world  leader  in  defense-related  graduate  education 
and  research  by  the  year  2000.  The  intent  is  to  provide  the  future  leaders  of  the  armed 
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services  with  the  technical,  analytical,  and  managerial  skills  needed  to  create  and  sustain 
efficient,  cost-effective,  and  fuUy  combat-ready  military  forces  (Taylor  95). 

NPS  education  will  be  recognized  as  a  key  ingredient  in  the  career  development  of 
military  officers,  as  a  vital  enhancement  of  their  war  fighting  capabihties,  as  a  critical  step 
in  preparing  for  joint  and  combined  assignments,  and  as  a  key  element  leading  to  high  level 
leadership  positions  (Taylor  95). 

Currently,  personnel  are  assigned  to  NPS  for  an  average  tour  of  two  years. 
Unfortunately,  there  is  neither  enough  money  nor  time  to  send  every  officer  to  NPS.  One 
of  the  five  NPS  guiding  principles  is  to  invest  in  the  education,  training,  technology,  and 
facihties  needed  to  fulfill  the  mission.  Because  mihtary  and  DoD  personnel  are  scattered 
all  around  the  world,  it  is  difficult  for  NPS  to  educate  those  people  who  are  unable  to 
attend  formal  training.  One  potential  solution  to  this  problem  is  the  increasing  network 
connectivity  within  DbD  and  military  institutions.  If  they  do  not  have  the  technology 
today,  then  they  are  likely  to  in  the  future.  With  network  connectivity  comes  the 
capability  to  institute  a  distance  learning  program  Although  the  Navy  has  conducted 
previous  research  in  the  area  of  video  teletraining,  what  makes  this  research  different  is  a 
new  technical  capability  called  the  MBone. 

C.  THE  MULTICAST  BACKBONE  (MBone) 

The  MBone  was  developed  as  a  tool  that  allows  researchers  to  communicate  using 
audio  and  video  over  the  Internet.  Until  a  few  years  ago,  people  thought  that  the  Internet 
could  not  support  the  transmission  of  live  audio  and  video.  Although  the  robustness  of 
the  Internet  Protocol  (IP)  leads  people  to  believe  that  the  Internet  cannot  be  broken,  it 
does  have  its  limits.  High-bandwidth  appUcations  such  as  audio  and  video  are  pushing 
these  limits  to  the  extreme. 

One  common  analogy  is  that  the  Internet  is  like  a  fi-eeway.  The  more  cars  there 
are  on  the  road,  the  longer  it  takes  to  get  to  work.  Sometimes  there  are  accidents  or 
coUisions,  which  can  cause  even  greater  delays.  As  more  cars  are  built,  more  cars  get  on 
the  fi'eeway,  causing  even  more  congestion.  Every  time  another  car  gets  on  a  busy 
fi-eeway,  it  causes  others  to  slow  down.  When  drivers  have  to  slow  down  or  are  even 


20 


forced  to  get  off  the  freeway  until  another  time,  delays  become  unacceptable.  Sunilarly, 
the  Internet  can  take  only  so  much  traffic  before  quality  of  service  becomes  an  issue.  The 
more  users  are  active  on  the  Internet,  the  greater  the  chance  that  other  users  are  affected. 
Therefore,  the  quahty  of  service  degrades. 

Chapter  V  provides  a  detailed  look  at  the  MBone.  Appendix  A  explains  how  to 
use  the  MBone  tools. 

D.  THE  CASE  STUDY 

Using  the  MBone,  an  NFS  course  was  transmitted  live  to  the  world  three  times  a 
week.  As  discussed  in  Chapter  I,  audio  and  video  take  up  a  lot  of  bandwidth. 

Transferring  huge  amounts  of  bandwidth,  such  as  the  kind  associated  with  digitized  video 
and  audio  traffic,  can  bring  most  networking  technology  to  a  standstill.  Thus,  many  open 
questions  had  to  be  addressed. 

The  use  of  audio  and  video  on  the  Internet  is  increasing  (Muirden  95).  Today, 
most  events  on  the  MBone  are  localized  or  special  one-shot  events-perhaps  for  one  day 
at  a  time  or  for  a  whole  week.  Because  the  Internet  currently  lacks  the  capacity  for 
everyone  to  mtilticast  everywhere  simultaneously,  coexisting  with  other  users  on  the 
Internet  using  both  audio  and  video  on  a  regular  production  basis  has  not  previously  been 
attempted. 

This  case  study  consisted  of  broadcasting  a  total  of  3.1  lectures  from  Dr.  Richard 
Hamming’.*;  course  “Learning  to  Learn”  over  an  entire  academic  quarter.  By  conducting 
this  study,  the  author  attempted  to  prove  that  the  MBone  can  sustain  the  impact  of  an 
ongoing  event,  and  remote  participants  would  receive  Dr.  Hamming’s  class  on  schedule. 

This  project  presented  two  obstacles.  The  first  is  a  technical  issue.  The  Internet 
can  handle  only  so  much  bandwidth  before  signal  quality  begins  to  degrade.  The  remote 
participants  must  be  able  to  understand  what  the  instructor  is  saying.  When  numerous 
users  utilize  the  MBone,  the  Internet  connections  can  become  bogged  down,  producing 
terrible  signal  quality  or  maybe  no  signal  at  all. 

The  second  obstacle  deals  with  human  issues  relating  to  a  shared  resource.  Global 
MBone  bandwidth  is  estimated  at  only  500  Kbps.  A  site  wishing  to  broadcast  a  special 
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event  might  find  itself  limited  by  another  site’s  existing  event.  To  try  to  alleviate  any 
problems  that  might  occur,  the  author  annotmced  the  plan  to  broadcast  the  course  and  the 
willingness  to  make  schedule  adjustments,  when  necessary.  Chapter  V  describes  the  case 
study  in  detail. 

E.  SUMMARY 

The  goal  of  this  thesis  was  to  prove  that  the  MBone  can  sustain  the  bandwidth 
constraints  and  uncertainties  associated  with  the  Internet.  Due  to  the  large  amounts  of 
bandwidth  consumed  by  audio  and  video,  and  the  problems  that  exist  with  a  shared 
network,  it  is  difficult  to  achieve  a  signal  quality  that  is  acceptable  enough  for  distance 
learning. 

The  case  study  demonstrated  that  distance  learning  over  the  Internet  will  work. 
The  research  in  this  thesis  applies  a  new  technical  capability  called  the  MBone  to  the 
Naval  Postgraduate  School  goals  of  providing  distance  learning  and  can  be  utilized  to 
expand  the  role  of  NFS  in  a  much  more  economical  way. 
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V.  THE  HAMMING  MULTICAST 


A.  INTRODUCTION 

The  purpose  of  this  research  was  to  test  the  MBone’s  ability  to  sustain  an  ongoing 
event  fisr  use  in  the  field  of  distance  learning.  Live  audio  and  video  of  a  course  taught  at 
the  Naval  Postgraduate  School  (NPS)  were  sent  to  participants  world-wide  three  times 
per  week  for  a  full  academic  quarter.  The  objective  of  this  research  was  to  “push  back  the 
envelope”  regarding  the  kinds  of  programming  that  are  possible  on  the  MBone.  The 
course  was  transmitted  on  a  global  chaimel  to  test  the  ability  of  transmitting  for  an 
extended  period  of  time-in  this  case,  for  eleven  weeks.  The  goal  was  to  learn  some  new 
lessons  and  to  then  distribute  both  results  and  recommendations  to  the  MBone 
conununity.  This  effort  involved  finding  a  location  with  suitable  attributes  for  an  MBone 
broadcast,  providing  network  connectivity,  installing  and  connecting  necessary  equipment, 
and  finding  an  instructor  who  would  agree  to  be  part  of  an  Internet  first  and  was  wilhng  to 
be  taped  while  lecturing  to  the  world.  This  chapter  describes  how  each  of  these  efforts 
was  accomplished  and  why  certain  decisions  were  made.  It  also  provides  detailed 
accounts  of  the  problems  that  occurred. 

B.  PRODUCTION  REQUIREMENTS 

The  first  step  was  finding  a  location  to  meet  the  network,  electrical,  and  acoustical 
requirements.  The  room  also  needed  to  be  large  enough  to  hold  a  class  of  about  60-75 
students.  Initially,  a  number  of  locations  on  campus  appeared  to  possess  the  physical 
characteristics  necessary  to  broadcast  a  course  over  the  MBone.  They  were  the 
auditoriums  in  Glasgow  and  Ingersoll  Halls,  various  classrooms  in  Spanagel  Hah,  and  the 
newly  constructed  auditorium  next  to  Melville  Hall.  However,  munerous  difficulties 
emerged; 

The  Glasgow  auditorium  (room  109)  had  an  audio  visual  projection  room  and  was 
large  enough  for  the  expected  number  of  students.  However,  its  acoustics  were 
inadequate.  The  auditorium  in  Ingersoll  (room  122)  had  an  audio  visual  projection  room, 
excellent  acoustics,  and  enough  room  for  about  100  students.  However,  Ingersoll  122  is 
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used  for  a  number  of  conferences  which  hold  a  higher  priority.  If  a  scheduling  confhct 
were  to  arise,  the  class  would  have  to  relocate  for  that  period  of  time.  Spanagel  Hall  had 
a  number  of  rooms  that  were  large  enough  and  that  had  good  acoustics,  but  none  of  them 
had  audio  visual  capabilities.  The  equipment  used  for  the  multicast  would  have  to  be 
moved  in  and  out  of  the  classroom  three  times  a  week.  This  would  take  a  lot  more  work 
and  had  a  great  potential  for  equipment  problems  to  occur.  The  auditorium  by  Melville 
Hall  had  the  best  acoustics,  excellent  lighting  conditions,  would  hold  close  to  100 
students,  and  had  an  audio  visual  projection  booth.  However,  it  lacked  network 
connections  and  equipment  in  the  booth,  and  the  building  itself  was  still  imder 
construction  and  would  not  be  finished  by  the  beginning  of  quarter.  After  careful 
consideration  of  all  options,  the  author  chose  the  new  auditorium  by  Melville  Hall  as  the 
most  suitable  location. 

The  following  section  discusses  the  measures  taken  to  prepare  the  auditorimn  to 
be  an  MBone  distance  learning  environment. 

1.  Network  Setup 

The  top  priority  was  network  connectivity.  NFS  employees,  along  with  an  outside 
contractor,  installed  a  fiber  to  Ethernet  adapter  in  the  projection  booth.  The  MBone 
tunnel  was  successfully  configured  to  include  the  appropriate  LAN,  and  it  tested  out 
satisfactorily. 

2.  Hardware/Software 

A  Silicon  Graphics  Inc.  (SGI)  Indy  workstation  was  set  up  in  the  AV  booth  of  the 
auditorium.  The  MBone  software  tools  and  an  electronic  mail  tool  were  loaded  on  the 
Indy.  Currently,  there  are  no  monitoring  tools  for  the  MBone.  As  a  result,  the  only  way 
to  receive  immediate  feedback  about  the  quality  of  a  signal  at  some  remote  site  is  via  e- 
mail.  E-mail  was  monitored  through  a  telnet  window. 

All  classes  were  broadcast  with  audio  and  video.  The  annoimcement  appeared  in 
the  Session  Directory  (sd)  under  “Hamming:  Learning  to  Learn.”  This  session  was 
created  at  the  beginning  of  the  quarter  and  remained  there  until  the  end.  The  scope  of  the 
sessions  was  set  to  til  =  127,  global  transmission.  Video  was  transmitted  using  Network 


24 


Video  (nv)  for  maYimiim  compatibility  with  remote  users.  The  bandwidth  was  kept  at  the 
default  of  128  Kbps.  Audio  was  transmitted  using  Visual  Audio  Tool  (vat).  The  default 
audio  input  was  changed  from  microphone  mode  to  line-in  mode.  The  gain  level  sUder 
was  adjusted  as  required  during  each  lecture,  and  adjustments  to  the  scope  and  bandwidth 
were  made  when  scheduling  conflicts  arose. 

Under  the  Menu  button  from  vat.  Lecture  Mode  was  selected  over  the  default 
Conference  Mode  because  this  was  a  noninteractive  session,  and  Lecture  Mode  results  in 
a  better  quality  signal.  The  Silence  Suppress  was  also  turned  ofi^  allowing  the 
transmitting  site  to  keep  the  focus  of  the  audio  session  and  making  it  difiScult  for  other 
sites  to  send  audio  on  that  session.  The  User’s  Guide  for  the  MBone  in  Appendix  A 
provides  a  more  detailed  description  of  the  MBone  software  tools  and  setup  selections. 

3.  Audio  Visual  Setup 

The  basic  audio  visual  requirements  are  known:  a  standard  video  camera  with  a 
tripod,  a  TV  monitor,  and  a  VCR  which  was  used  to  tape  each  lecture  while  it  was  being 
broadcast.  Because  the  audio  visual  booth  was  in  a  separate  room  inside  the  auditorimn, 
audio  was  provided  using  a  wireless  microphone  given  to  the  professor  before  each 
lecture.  No  attenq)t  was  made  to  include  the  MBone  audience(s)  in  the  audio  portion  of 
the  lectures.  Taking  questions  from  the  network  required  a  sound  system  for  the 
auditorium  (so  the  NFS  audience  could  hear  the  questions).  Since  this  capability  was  not 
part  of  the  research  at  the  time,  questions  were  taken  via  e-mail. 

The  professor’s  requirements  were  unknown.  If  computer-generated  video  were 
used,  it  would  have  to  be  scan-converted  to  NTSC  (National  Television  Standards 
Committee).  If  traditional  overhead  slides  were  used,  the  best  way  to  pipe  them  into  the 
MBone  would  have  to  be  determined.  Another  consideration  was  that  video  projection 
causes  lighting  problems  if  there  are  cameras  in  the  room. 

Once  requirements  were  properly  identified,  personnel  from  the  NPS  AV 
department  worked  several  hours  to  set  up  the  equipment  in  the  projection  booth.  After 
the  first  day  of  testing,  the  camera  was  inadvertently  left  on  overnight.  As  a  result,  it 
overheated  and  failed.  After  the  camera  was  replaced,  all  of  the  wiring  had  to  be  redone. 
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Audio/video  checks  for  both  MBone  and  the  VCR  were  then  satisfactory.  To  prevent 
errors  such  as  the  one  mentioned  above,  the  following  checklist,  covering  everything  from 
the  equipment  to  the  building  itself^  was  created: 

(1)  Room 

-  Lights  =>  All  on  except  light  above  board  &  light  in  booth 

-  Doors  =>  Close  auditorium  doors  when  class  begins 

-  Lectern  =>  Is  it  stiU  there? 

-  Markers/Erasers  =>  Only  black  &  red  for  maximum  contrast 

-  Close  door  to  projection  booth 

-  Erase  board  after  lecture 

-  Lock  doors  \^^en  finished 

(2)  Video/Audio  Equipment 

-  Power  button  on  top  of  camera 

-  Lens  cap  off 

-  Turn  on  TV 

-  Turn  on  VCR 

-  Put  in  new  tape/cue  tape 

--  Ensure  only  two  lectures/tape 
—  Label  tapes  with  title,  lecture  number  and  date 

-  Set  record  speed  to  SP  for  best  quality 

-  Start  recording  ~  3  minutes  prior  to  actual  start 

-  Turn  on  wireless  microphone  and  test 

(3)  Workstation 

-  Login 

-  Open  session  directory  (sd)  via  console 

-  Open  Hamming  session  from  sd  menu 

-  Set  audio  panel  MENU  to  the  following: 
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—  no  silence  suppress 

—  lecture  mode 

-  Change  the  microphone  icon  to  digital  input 

-  Select  “Keep  Audio”  to  ensure  this  is  active  session 

-  Video  panel;  Verify  bandwidth:  128  Kbps 

(4)  Important  Phone  Numbers  List  Handy 

(5)  Network  Monitoring  Tools 

-  Etherview  =>  /usr/etc/etherview  -g 

C.  COURSE  INFORMATION 

Dr.  Richard  Hamming  accepted  the  request  to  participate  in  this  world-wide 
experiment.  Dr.  Hamming  received  a  Ph.D.  in  Mathematics  from  the  University  of  Illinois 
in  1942.  He  worked  at  Los  Alamos  from  1945  to  1946,  at  Bell  Laboratories  from  1946  to 
1976,  served  three  years  at  Princeton  University  as  an  Adjunct  Professor  of  Statistics,  and 
joined  the  Naval  Postgraduate  School  in  1976.  Dr.  Hamming  is  a  past  president  of  the 
Association  for  Con:q)uting  Machinery  (ACM)  and  recipient  of  the  Turing  Prize  of  the 
ACM.  He  is  both  namesake  and  a  recipient  of  the  IEEE  R.W.  Hamming  medal  and  has 
received  a  large  variety  of  other  awards.  Dr.  Hamming  is  the  author  of  numerous  papers 
and  books. 

The  name  of  his  course  is  “The  Art  of  Doing  Science  and  Engineering;  Learning 
to  Leam.”  It  is  often  referred  to  as  “Hamming  on  Hamming”  due  to  the  fact  that  Dr. 
Hamming’s  work  began  or  greatly  influenced  many  of  the  subject  areas  covered  in  his 
course.  Topics  include:  foimdations  of  the  digital  (discrete)  revolution,  foundations  of 
conq)uter  hardware/software/apphcations;  limits  of  conq)uter  applications  and  artificial 
intelligence  (AI);  N-dimensional  space,  coding  theoiy,  error  correcting  codes,  information 
theory,  digital  filters,  simulation,  fiber  optics,  computer-aided  instruction  (CAI), 
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mathematics,  quantum  mechanics,  creativity,  experts,  unrehable  data,  and  systems 
engineering.  Dr.  Hamming  has  written  about  his  course: 


I  will  examine,  criticize  and  display  styles  of  thinking.  To  illustrate  the  points 
of  style  I  will  often  use  technical  knowledge  that  most  of  you  know.  ...  You 
should  regard  this  as  a  course  that  complements  the  many  technical  courses 
you  have  learned.  Many  of  the  things  I  will  talk  about  are  things  that  I  believe 
you  ought  to  know  but  which  simply  do  not  fit  into  courses  in  the  standard 
curriculum. . .  The  course  is  concerned  with  ‘style,’  and  almost  by  defimtion 
style  caimot  be  taught  in  the  normal  maimer  by  using  words.  I  can  only 
approach  the  topic  through  particular  exanqiles,  which  I  hope  are  well  within 
your  grasp,  though  the  examples  come  mainly  fi'om  my  30  years  in  the 
mathematics  department  of  the  Research  Division  of  the  Bell  Telephone 
Laboratories,  (before  it  was  broken  up).  It  also  comes  fi^om  years  of  study  of 
the  work  of  others.  (Hamming  95) 

D.  RESULTS 

1.  Findings 

Classes  were  held  Tuesdays  and  Thursdays  fi'om  1210-1300  Pacific  (1910-2000 
GMT)  and  Fridays  fiom  1410-1500  Pacific  (2110-2200  GMT).  A  total  of  3 1  lectures 
were  broadcast  between  March  28  and  June  6,  1995.  Observations  were  made  and  are 
documented  in  the  following  sections.  The  findings  are  broken  up  into  these  categories: 
Camera  Work,  Audio  Issues,  Scheduling  Issues,  Statistical  Information,  Room  Issues,  and 
Miscellaneous  Findings. 

a.  Camera  Work 

The  first  day  of  class,  the  author  met  with  Dr.  Hamming  to  go  over 
procedures  for  the  multicast.  Dr.  Hamming  warned  that  he  walked  around  quite  a  bit,  so 
camera  work  might  be  tricky.  He  also  requested  that  the  students  in  the  classroom  be 
included  in  the  broadcast  as  well.  Dr.  Hamming  felt  the  remote  viewers  might  become 
bored  with  seeing  only  his  face.  He  also  requested  there  be  a  clock  and  a  lectern  in  the 
room 

During  these  broadcasts,  the  author  observed  the  lectures  fiom  the  video 
camera,  video  monitor,  and  SGI  workstation  inside  the  AV  booth  of  the  auditorium 
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Being  on  the  receiving  end  of  an  MBone  broadcast  allowed  the  author  to  make  some 
interesting  observations.  First,  traditional  video  taping,  with  constant  movement  of  the 
camera,  is  not  appropriate  for  MBone  transmissions.  Because  of  the  slow  frame  rates 
associated  with  MBone  transmissions,  a  lot  of  camera  movement  will  generally  cause 
image  loss,  causing  the  viewer  to  miss  out  on  certain  elements  of  a  presentation.  As  the 
speaker  moves  around,  it  works  best  to  pan  back  and  hold  the  image  of  the  instructor  as 
he/she  moves  around  the  room.  Sometimes  it  is  easier  for  remote  viewers  to  understand  a 
lecture  if  close-ups  of  the  speaker  are  filmed  as  he/she  is  standing  at  a  lectern  or  in  one 
position  for  awhile  An  alternative  is  having  a  second  camera  on  hand.  The  ability  to 
switch  between  cameras  opens  up  a  new  angle  for  producing  a  more  professional-looking 
show. 

When  video  taping  information,  equations,  etc.,  from  a  chalkboard  or  dry 
eraser  board,  it  is  best  to  put  the  camera  on  the  information  and  hold  it  for  at  least  three  to 
four  seconds.  Holding  the  camera  steady  gives  the  image  a  chance  to  fully  update  and 
provides  remote  viewers  a  chance  to  focus  on  the  information.  Moving  the  camera  back 
and  forth  only  results  in  lost  data. 

Another  observation  was  that  red  and  black  markers  were  the  only  ones 
that  could  be  seen  on  the  MBone.  The  camera  had  a  difficult  time  focusing  on  blue  ones. 

b.  Scheduling  Issues 

The  “Hamming”  lecture  series  was  announced  prior  to  the  first  broadcast. 
Because  MBone  audio  and  video  sessions  can  consume  a  large  amomit  of  bandwidth, 
users  should  attenqrt  to  minimize  the  effect  of  MBone  traffic  on  other  users  of  the 
network.  For  example,  for  an  entire  week  in  April  1995,  the  World-Wide  Web  (WWW) 
conference  in  Germany  was  also  being  multicast  over  the  MBone.  As  a  result,  the 
Hamming  classes  were  broadcast  live  only  in  the  local  area  with  a  ttl  =16.  Later  in  the 
afternoon,  aroimd  4pm,  the  recorded  version  of  the  lectures  was  then  rebroadcast  world¬ 
wide  with  a  ttl  =  127.  Changes  such  as  these  must  be  announced  ahead  of  time  to  ensure 
that  off-campus  participants  could  arrange  their  schedules  accordingly.  Interestingly 
enough,  there  were  more  hsteners  during  that  week  than  at  any  other  time.  The  4pm  PST 
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broadcast  must  have  fit  into  everyone’s  schedule  better  and  remote  viewers  were  already 
online  from  the  WWW  conference. 

c  Audio  Issues 

As  previously  stated,  since  the  equipment  used  for  the  MBone  multicast 
was  located  inside  the  booth  of  the  auditorium,  it  was  necessary  to  put  a  wireless 
microphone  on  Dr.  Hamming  before  each  lecture.  Finding  the  perfect  location  on  Dr. 
Hamming’  s  tie  was  important.  Placing  the  microphone  too  high  resulted  in  a  lot  of  noise 
in  the  signal  Too  low  and  it  became  difficult  to  hear  him.  Keeping  the  volume  up  on  the 
TV  was  a  good  way  to  tell  if  the  volume  was  working.  The  audio  signal  should  be  tested 
before  beginning  transmission.  Sometimes,  a  weak  signal  just  meant  the  battery  was 
running  down,  SO  a  supply  of  spare  batteries  was  kept  handy. 

Dr.  Hamming’s  lectures,  with  the  exception  of  one,  were  just  that— 
lectures.  Students  did  not  ask  questions  and  rarely  challenged  his  ideas.  A  different 
format  would  have  been  more  difficult  for  the  researchers  because  the  students'  questions 
could  have  been  heard  only  if  Dr.  Hamming  took  off  the  wireless  microphone  and  passed 
it  around.  The  exception  to  this  format  was  a  lecture  intentionally  designed  to  provoke 
interaction  among  the  students.  The  lecture  was  titled,  “Can  machines  think?”  Dr. 
Hamming  asked  his  students  to  come  to  class  prepared  with  thought-out  responses  to  this 
question.  He  also  required  the  students  to  sit  in  the  fi’ont  two  rows  of  the  auditorium; 
thus,  the  camera  work  was  easier  to  perform.  In  order  to  hear  every  student’s  response. 
Dr.  Hamming  passed  around  the  wireless  microphone.  For  the  most  part,  this  worked; 
however,  Dr.  Hamming,  sometimes  forgot  that  he  was  no  longer  wearing  the  microphone, 
and  some  of  his  conversation  was  never  heard.  A  better  alternative  is  to  have  two 
microphones,  a  lapel  microphone  for  the  speaker  and  a  hand-held  microphone  that  the 
students  could  pass  around. 

d.  Miscellaneous  Findings 

Although  the  auditorium  was  in  a  brand  new  building,  it  had  problems. 

The  remote  controlled  blinds  weren’t  working,  so  it  was  difficult  to  tape  the  students  who 
were  in  line  with  the  windows.  Also,  since  the  AV  booth  was  painted  white  and  contained 
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two  large  windows,  there  was  some  glare  in  the  camera  signal.  The  author  recommends 
the  walls  be  painted  black  and  the  windows  be  covered  with  some  black  curtains  to  cut 
down  the  glare. 

2.  Problems  Encountered 

During  the  quarter,  only  one  major  problem  occurred,  but,  unfortunately,  it  lasted 
for  a  week  until  a  team  of  NPS  personnel  finally  discovered  the  cause.  During  the  week  of 
May  1-5,  the  transmission  experienced  50  percent  losses  at  the  transmitting  workstation 
located  inside  the  AV  booth  of  the  auditorium  This  first  occurred  on  a  Friday  afternoon, 
when  was  no  one  was  around  to  solve  the  problem  During  the  next  lecture,  there  was 
again  a  packet  loss  of  50  percent,  surprising  since  there  were  no  other  significant 
processes  running  on  that  machine.  The  systems  administrator  was  contacted  about  the 
problem  Thinking  the  problem  was  local  with  the  transmitting  workstation,  the  author 
rebooted  the  machine  That  did  not  fix  the  problem  Packet  loss  on  the  local  machine 
usually  means  there  are  problems  with  the  local  area  network  (LAN).  So,  a  previously 
created  NPS  session  was  opened  and  tested.  There  were  no  losses  on  that  session.  One 
theory  was  that  there  was  a  host  on  the  MBone  sending  the  ‘Hamming’  machine  a 
constant  message  to  stop  sending. 

A  variety  of  e?q)eriments  and  network  tests  gave  conflicting  indications.  Finally, 
the  system  administrator  loaded  a  copy  of ‘^therview”  on  the  “Hamming”  machine. 
Etherview  is  a  pubhc-domain  network  visualizer  program  with  a  graphical  display  (Hull 
91).  It  provides  a  detailed  look  at  network  traffic  v^hich  finally  permitted  the  problem  to 
be  discovered.  By  filtering  out  TCP  and  UDP  traffic,  it  was  discovered  that  the  NPS 
mainframe  (yml.cc.rqjs.navy.mil,  131.120.50.50)  was  sending  a  constant  stream  of 
Internet  Control  Management  Protocol  (ICMP)  packets  to  the  transmitting  workstation. 
Apparently,  the  mainframe  had  faulty  code  which  did  not  understand  multicast.  Every 
time  the  “Hamming”  machine  sent  a  multicast  packet,  vml  would  send  back  a  “check” 
message  provoking  the  50  percent  loss  at  the  source.  The  difficulty  happened  only  for 
streams  originating  within  NPS  with  ttl  >  16.  This  problem  lasted  for  an  entire  week. 
Fortunately,  it  did  not  affect  others  out  there  wishing  to  transmit.  The  answer  was  not 
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easy  to  find,  even  for  the  system  administrators.  Dropping  the  MBone  tunnel  that 
connected  the  faulty  mainframe  removed  the  problem 

Recommendation:  have  a  graphical  tool  like  Etherview  continuously  available  for 
any  serious  multicasting.  The  diagnosis  capabilities  are  essential.  Other  tools,  such  as 
tcpdmr^,  also  work  if  time  is  made  to  learn  the  syntax.  Root  permission  is  required  to  run 
these  tools,  so  preparation  that  includes  the  system  administrator  is  also  necessary.  The 
problem  the  researchers  encoimtered  is  a  good  example  of  how  volatile  the  MBone  can 
be.  Because  the  MBone  is  experimental,  keeping  in  touch  with  the  MBone  commimity  via 
the  MBone  mail  list  is  always  a  good  idea.  There  are  others  out  there  willing  to  help  with 
troubleshooting.  Network  monitoring  is  a  good  area  for  future  work. 

3.  Feedback  from  Viewers 
a.  Who  Watched? 

The  goal  of  the  research  project  was  to  find  out  if  an  ongoing  event  could 
take  place  on  the  MBone.  Feedback  via  e-mail  firom  remote  participants  was  the  only 
indication  of  whether  or  not  the  project  was  successful.  Some  people  responded 
immediately,  sometimes  even  during  a  lecture  if  they  were  experiencing  difficulties--  audio 
not  getting  through,  for  example.  Other  feedback  was  via  the  vat  name  window. 

On  average,  there  were  ten  listeners  per  lecture,  and  sometimes  as  few  as 
three  and  as  many  as  33.  Of  these  numbers,  five  of  the  participants  were  almost  always 
listening.  Often,  a  number  of  remote  participants  would  join  in  the  session,  stay  for  a  few 
minutes,  and  then  exit.  Events  on  the  MBone  are  similar  to  those  of  a  TV  station. 

Viewers  scan  through  various  sessions  to  see  if  there  are  one  or  two  that  appear 
interesting  enough  to  keep  them  on  the  line.  The  following  is  a  snapshot  of  a  remote 
audience  for  the  lecture  held  on  April  25,  1995.  Most  of  these  participants  remained 
‘tuned  in’  for  the  entire  lecture,  perhaps  because  they  considered  the  lecture  material 
impmtantj  the  signal  quality  was  acceptable  enough  for  users  to  imderstand  the  material, 
and,  finally,  there  may  not  have  been  any  other  events  occurring  at  that  time. 
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mccann@merak.cc.nps.navy.mil  [131.120.53.5*] 
root@prince.proteon.com  [128. 185.37.49] 

Gorm  Haug  Eriksen,  Univ.  of  Oslo,  Norway  [129.240.200.192] 
Teije  Vemly  (teijeve@usit.uio.no)  [129.240.200.25] 

Eric  Klinker  (NRL)  [132.250.198.17] 
visio@cisnmiedia.univ-lyonl.fr  [134.214. 180.2] 
gb@darmok.cs.utah.edu  [155.99.208. 1] 
hamming.me.nps.navy.mil  [131. 120. 151.59] 
brutzman@nps.navy.mil  (fletch.stl...)  [131.120.63.31] 

Don  Merritt  (ARL)  [128.63.58.52] 

Larry  Blunk  (Merit)  [198. 108.60. 101] 

Marc  Michelsen  (Univ  of  Wash  -  Seattle)  [128.95. 176. 121] 
Steve  Casner  (ISI)  [128.9. 160. 100] 
hudson@coast.usw.nps.navy.mil  [131.120.62.8] 
hopper@enq)yrean. ucsd.edu  [132.239.5 1.61] 
test@mcast  [132.197.160.10] 
enm@sgilO.hep.anl.gov  [146.139.180.11] 
chas@volt.nrl.navy.mil  [132.250. 1 10. 120] 

Joe  Macker  (NRL)  [132.250.92. 160] 

Dan  Molinelli  (TRW.COM)  [129.4.53. 1 1] 
deba@keUer.lbl.gov  [128.3.196.47] 

Bob  Braden  (ISI)  [128.9.160.148] 
mchugh@zetar.cs.pdx.edu  [13 1.252.21.203] 
daasch@crueUa.ee.pdx.edu  [13 1.252. 10. 177] 
beattie@grifiy.lbl.gov  [128.3.196.33] 
daniel@fra.isi.edu  [128.9.160.58] 
berson@mex.isi.edu  [128.9. 160. 150] 
jfs@golum.hrb.com  [149.145.2.98] 
topolcic@PEREGRINE.BBN.COM  [128.89.6. 129] 
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trac@ouriris.nps.navy.niil  [13 1. 120.57.47] 
elbert@elbert.ameslab.gov  [147. 155.30.3] 
vvilliams@canopus.cc.nps.navy.niil  [131.120.143.126] 

Ron  Broersma  (NRaD,  San  Diego)  [128.49.192.11] 

b.  Quality  of  Audio  and  Video 

Audio  is  the  most  important  part  of  a  video  teleconference.  Our 
experience  has  shown  that  audio  is  always  a  bigger  challenge  than  video.  Human 
cognitive  abilities  allow  us  to  fill  in  the  blanks  As  stated  earUer,  camera  work  can  have  a 
serious  effect  on  what  remote  participants  see.  However,  if  the  camera  is  following  Dr. 
Hamming  walking  back  and  forth  as  he  lectures,  it  doesn’t  really  matter  if  the  viewer 
misses  a  frame  or  two.  It  is  clear  that  Dr.  Hamming  is  walking  back  and  forth.  However, 
if  packets  of  audio  drop  out,  the  problem  is  far  more  serious.  It  is  not  as  easy  to  fill  in 
those  blanks,  especially  if  the  viewer  is  unfamiliar  with  the  subject  area. 

For  the  most  part,  the  quality  of  the  audio  and  video  signals  were  good.  At 
the  beginning  of  the  quarter  there  was  a  zero  percent  audio  loss,  and  fi'om  then  on  a  steady 
three  percent  loss  appeared.  For  two  lectures,  a  30  percent  audio  loss  was  reported 
across  the  NFS  campus.  Nothing  was  reported  fi’om  areas  outside  NFS.  Without  remote 
participant  feedback,  there  was  no  way  to  determine  exactly  vriiat  was  happening  on  the 
other  end  of  the  broadcast.  Steady  attendance  leads  us  to  believe  that  remote  signal 
quahty  was  adequate  for  most  sections  of  the  MBone. 

c.  Suggestions 

When  broadcasting  on  a  global  channel,  announcements  should  be  made 
either  in  local  time  (if  they  are  scheduled  according  to  local  time)  or  in  GMT  (if  they  are 
scheduled  in  GMT).  A  handy  time  converter  exists  and  can  be  found  online  at 
http://hibp.ecse.rpi.edu/cgi-bin/tzconvert  (Stewart  95). 

There  was  some  concern  fi’om  one  overseas  participant  about  even  having 
the  capabUity  to  receive  such  a  broadcast.  How  do  those  people  who  cannot  effectively 
participate  due  to  bandwidth  limitations  participate?  What  is  the  point  of  trying  to  educate 


34 


if  the  students  cannot  hear  the  instructor?  The  idea  was  expressed  that,  until  more 
bandwidth  is  made  available,  distance  education  on  a  global  basis  using  the  MBone  will, 
unfortunately,  remain  very  limited. 

In  response  to  this  concern,  a  group  from  the  London  College  known  as 
the  Multimedia  Integrated  Conferencing  for  Europe  (MICE)  offered  to  rebroadcast  the 
lectmes  over  a  European  channel  only  (Handley).  Copies  of  the  original  lecture  tapes 
were  made  and  sent  to  MICE,  which  has  not  only  been  rebroadcasting  the  lectures,  but 
also  has  been  working  on  a  cohaborative  plan  to  digitize  the  tapes  and  archive  them  on  the 
World  Wide  Web. 

Scheduling  events  is  very  important,  especially  if  they  are  to  be  transmitted 
on  a  global  channel.  Events  can  be  announced  by  sending  a  message  to  the  MBone 
mailing  list  called  rem-conf@,es.net  and  also  by  using  the  online  MBone  Global  Agenda 
located  at  http://www.cilea.it/MBone/agenda.html. 

4.  Dr.  Hamming’s  Comments 

Dr.  Hamming  believes  that  to  prepare  for  the  foture,  students  need  to  forge  then- 
own  style  and  create  their  own  vision.  have  my  feet  planted  in  a  prior  generation.  I 
want  the  students  to  question  me  and  think  for  themselves,”  stated  Hamming. 

Is  distance  learning  a  door  to  the  future  of  education?  Dr.  Hamming  says  “yes  and 
no.”  Although  there  have  been  studies  documenting  the  effectiveness  of  distance  learning. 
Dr.  Hamming  feels  there  is  something  about  a  live  human  being  which  does  not  seem  to 
get  through  the  distance  learning  mediiun.  There  is  an  aspect  of  group  behavior  that  has  a 
different  affect  on  a  classroom  fell  of  students  versus  a  single  student  “tuning  in”  to  a 
lecture. 

Another  dubious  element  of  distance  learning  is  the  viewing  mode  of  the  student. 
Watching  television,  for  example,  puts  one  into  a  passive  mode  of  viewing.  Dr.  Hamming 
feels  the  same  thing  happens  to  a  student  learning  from  a  computer  monitor.  The  student 
learns  in  a  more  passive  manner  and  tends  not  to  argue  or  debate  with  the  instructor. 
Something  is  lost  from  the  learning  process.  Dr.  Hamming  is  quick  to  note  that,  although 
he  cannot  say  what  that  “something”  is,  distance  learning  is  better  than  nothing.  As  long 
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as  course  requirements  are  met,  a  remote  student  should  receive  credit.  It’s  just  a  matter 
of  learning  and  being  taught.  “What  you  learn  from  others  you  could  use  to  follow,  what 
you  leam  for  yourself  you  can  use  to  lead,”  stated  Hamming. 

One  of  the  purposes  of  a  class  is  to  force  regular  attendance;  otherwise  the 
learning  is  postponed.  Without  the  actual  requirement  to  be  there,  it  becomes  too  easy  to 
do  other  things  at  the  same  time  or  even  stop  listening  altogether.  Also,  when  a  student  is 
required  to  attend  a  class,  there  seems  to  be  more  put  into  it  ahead  of  time.  The  student 
tends  to  mentally  prepare  himself  for  the  lectme.  There  are  fewer  distractions  in  a 
classroom  to  hinder  the  learning  process. 

When  asked  if  this  research  affected  his  teaching  style  or  lecture  material.  Dr. 
Hamming  said  he  had  to  make  adjustments  in  both  areas.  Noting  that  the  first  lecture  is 
always  the  hardest  in  any  teaching  situation.  Dr.  Hamming  said  that  he  was  able  to  relax 
and  ignore  the  cameras  after  the  first  couple  of  lectures.  It  did  not  bother  him  that  his 
lectures  were  going  out  live  over  the  Internet.  He  could  not  afford  to  let  it.  He  sinq)ly 
adopted  a  “so  what?”  attitude. 

One  habit  did  change  slightly.  His  normal  teaching  routine  involves  walking  into 
the  classroom,  talking  to  one  or  two  students  and  then  beginning  his  lecture.  During  this 
research  project  he  arrived  early  to  each  lecture  to  get  ‘wired’  for  audio,  and  would  then 
sit  quietly  in  the  auditorium  to  prepare  his  thoughts.  He  also  made  a  change  in  his  lecture 
material.  Because  the  lectures  would  be  going  out  over  the  Internet,  he  eliminated 
portions  that  dealt  with  the  military  aspects  of  students’  experiences. 

It  was  noted  that  there  was  very  little  student  interaction  during  the  quarter.  The 
author  thought  the  students  might  be  inhibited  because  of  the  live  broadcast,  but  Dr. 
Hamming  stated  that  little  discussion  is  typical  when  the  class  is  so  large.  His  average 
class  size  is  60-70  students.  A  lack  of  student  feedback  concerning  the  research  project 
prevents  a  clear  understanding  of  this  issue.  If  he  could,  he  would  limit  the  number  of 
students  and  force  more  class  interaction. 

When  asked  his  opinion  regarding  the  types  of  comses  that  would  work  well  using 
distance  learning,  he  felt  that  it  wasn’t  a  question  of  a  good  course  versus  a  bad  one.  The 
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question  that  should  be  asked  is,  “What’s  the  alternative?”  Is  a  lecture  on  art  eliminated 
from  a  distance  learning  program  because  looking  at  the  pictures  over  a  computer  screen 
wouldn’t  be  as  good  as  being  there?  Would  those  remote  students  have  the  opportunity 
to  ever  see  those  pictures  again?  For  Dr.  Hamming’s  class,  a  class  of  30  might  be  better 
than  a  class  of  60,  but  would  the  benefits  of  a  smaller  class  outweigh  the  loss  to  students 
who  are  refused  enrollment?  The  ideal  situation  would  be  one  instructor  for  every 
student,  but  clearly  this  is  imrealistic.  Distance  learning,  though  not  ideal,  has  value. 

Dr.  Hamming  has  been  conq)letely  supportive  throughout  this  effort.  He  even 
repeated  a  lecture  without  benefit  of  audience  when  a  recording  mistake  ruined  a  tape.  It 
is  difficult  to  imagine  anyone  not  being  challenged  by  Dr.  Richard  Hamming’s  ideas. 

5.  Things  to  Consider 

Being  on  the  receiving  end  of  an  MBone  multicast,  the  author  was  able  to  make 
some  interesting  observations.  First,  even  slow  fi'ame  rate  video  seems  to  add  value  to 
the  conference.  The  fi'ame  rates  experienced  with  this  research  project  were  usually  in  the 
range  of  0.2-5  fiames  per  second.  Even  so,  video  still  seemed  to  create  a  sense  of 
presence  and  give  visual  clues.  Second,  it  can  be  valuable  to  be  able  to  do  other  things  at 
the  workstation  while  receiving  a  broadcast.  For  instance,  it  could  be  useful  to  look  up 
some  additional  information  by  telnetting  to  the  library  or  bringing  up  a  page  in  a  web 
browser.  However,  being  at  the  desktop  work  ^ace  can  also  be  a  disadvantage. 
Distractions  such  as  phone  calls  and  e-mail  can  divert  attention  away  fiom  the  multicast. 
E.  SUMMARY 

This  distance  learning  case  study  was  delivered  using  the  Internet’s  MBone.  The 
requirements  necessary  to  conduct  this  study  included  finding  a  suitable  location,  ensuring 
network  connectivity,  installing  equipment  and  finding  a  flexible  instructor  to  teach  the 
comrse.  The  findings  in  this  study  proved  that  the  MBone  is  a  viable  asset  for  distance 
learning.  A  number  of  questions  were  raised  throughout  the  quarter  leading  to  a  better 
understanding  of  the  MBone  and  the  concepts  of  distance  learning. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  RESEARCH  CONCLUSIONS 

The  Hamming  case  study  provided  the  opportunity  to  examine  the  use  of  the 
MBone  as  a  distance  learning  medium  for  global  use.  This  project  was  successful.  It 
disproves  earlier  beliefs  that  the  MBone  is  unable  to  sustain  an  ongoing  event.  The  goal 
was  to  prove  that  the  MBone  could  sustain  an  ongoing  event.  Of  the  3 1  lectures,  25  went 
out  live  as  scheduled.  Due  to  a  scheduling  conflict  with  the  World  Wide  Web  conference, 
three  lectures  had  to  be  retransmitted  on  a  global  channel,  at  a  later  time  in  the  day.  The 
other  three  lectures  went  out  one  week  late  because  of  a  network  problem  at  the 
transmitting  site.  The  symptoms  for  this  particular  problem  as  well  as  the  solution  have 
been  documented  so  that  in  the  future,  an  entire  week  of  transmitting  time  will  not  be  lost. 

Over  the  course  of  the  quarter,  there  were  an  average  often  listeners  per  lecture. 
Some  provided  feedback,  enabling  the  author  to  leam  about  the  quality  of  the  broadcast. 
The  results  of  the  study  would  be  more  useful  if  more  remote  participants  had  provided 
feedback.  As  a  result,  speculation  is  the  only  available  tool  for  determining  the  perceived 
signal  quality  of  remote  participants. 

The  MBone  uses  bandwidth  efficiently  which  makes  it  a  strong  candidate  for  large 
distributed  presentations.  Because  the  MBone  utilizes  the  Internet,  using  adequate 
equipment  and  providing  proper  training  will  reduce  problems  associated  with  shared 
networking.  This  work  demonstrates  that  effective  global  learning  using  the  MBone  is 
feasible.  It  also  shows  how  commands  can  save  on  travel  and  training  expenses  for 
personnel. 

The  downside  of  this  new  technical  capability  is  that  it  takes  a  lot  of  time  and 
effort  to  leam  and  effectively  use.  It  also  takes  some  attention  to  tecbmcal  details  so  it 
was  important  to  document  those  lessons  in  passing.  This  is  a  hi-tech,  experimental  tool 
that  is  not  well  understood.  As  a  result  of  this  thesis,  capabilities  that  were  once  thought 
impossible  are  now  available. 
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B.  RECOMMENDATIONS  FOR  FUTURE  WORK 

The  ability  to  use  the  MBone  for  an  ongoing  educational  project  such  as  distance 
learning  is  remarkable.  However,  as  already  stated,  there  are  problems  that  arise  when 
utili^g  a  shared  network,  especially  one  as  large  as  the  Internet.  It  would  save  time  and 
increase  usability  if  the  nature  and  location  of  these  problems  could  be  determined  as  they 
happen.  Currently,  users  rely  on  other  user  feedback.  This  system  only  alerts  the  sender 
of  a  problem,  it  doesn’t  solve  it.  There  is  a  need  for  monitoring  tools  that  will  help 
determine  the  quality  of  signals  received  at  other  locations. 

Another  recommendation  for  further  distance  learning  research  using  the  MBone  is 
to  atteiiq)t  an  interactive  course  on  a  global  scale,  possibly  using  2-3  different  mihtary 
commands  from  different  parts  of  the  United  States.  Better  statistical  information  can  be 
drawn  from  such  a  study  to  provide  a  deeper  look  into  the  audio  endurance  of  the  MBone 
and  help  find  out  the  perceived  effectiveness  of  the  MBone  as  a  distance  learning  tool 

Finally,  with  the  ability  to  view  audio  and  video  over  the  Internet  comes  the  desire 
to  archive  that  same  information.  Learning  how  to  digitize  these  large  amoimts  of  data 
and  store  them  in  the  most  efficient  way  is  important.  “Putting  it  on  the  Web”  provides 
even  more  flexibility.  It  allows  students  to  view  courses  at  a  time  that  is  more  convenient. 
It  gives  instructors  an  avenue  for  teaching  more  students.  One  can  build  an  educational 
video  library  for  media  on  demand  at  almost  zero  dollar  cost. 
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APPENDIX  A:  MBone  USER’S  GUIDE 

A.  INTRODUCTION 

This  user’s  guide  is  designed  to  assist  personnel  at  the  Naval  Postgraduate  School 
using  the  Mukicast  Backbone  (MBone)  for  desktop  conferencing.  There  are  no  instructions 
here  on  connecting  a  site  to  the  MBone.  To  determine  if  a  site  does  support  the  MBone,  just 
ask  the  local  network  support  people.  Information  on  how  to  connect  to  the  MBone  can  be 
found  in  the  MBone  Frequently  Asked  Questions  (Casner  93)  Ust,  or  Dan's  Quick  and  Dirty 
Guide  to  Getting  Connected  to  the  MBone  (Mosedale  94).  Section  J  contains  a  complete 
hsting  of  MBone  resources. 

B.  OVERVIEW  OF  THE  MBone 

The  Multicast  Backbone  (MBone)  originated  from  experiments  during  the  1992 
Internet  Engineering  Task  Force  (IETF)  conferences  in  San  Diego  and  Boston  in  which  live 
audio  and  video  were  transmitted  around  the  world.  The  MBone  currently  links  Unix 
workstations  and  has  been  called  a  ‘virtual  network’  because  it  uses  the  physical  Internet  to 
support  routing  of  Internet  Protocol  (IP)  multicast  packets.  On  a  multicast  network,  a  packet 
can  be  sent  once  from  machine  A  and  distributed  to  machines  B,  C  and  D  without  having  to 
send  the  original  packet  three  times. 

C.  USING  THE  MBone  TOOLS 

The  startup  file  for  the  MBone  tools  (called  .sd.tcl)  contains  default  audio  and  video 
apphcation  addresses.  To  change  these  apphcations  you  must  see  your  local  support  office. 
The  following  is  a  list  of  MBone  applications  available  on  the  Unix  workstations  at  the  Naval 
Postgraduate  School. 

1,  Session  Directory  (sdi\  Session  Directory  is  the  tool  used  to  manage  MBone 
sessions.  It  displays  available  sessions  and  can  be  used  to  create  new  ones.  To  use  the 
MBone  tools  simply  type  sd  at  the  shell  prompt.  Sessions  will  be  announced  in  the  session 
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directory  window  as  shown  in  figure  1 .  Clicking  on  a  session  name  gives  information  about 
the  session  such  as  time  and  date  of  transmission.  To  participate  in  a  session  press  the  Open 
button  or  double-chck  on  the  session  entry. 
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Figure  1.  Session  Directory  (sd) 


Figure  2,  New  Session  Directory  (sd) 
window 


A  new  sd  session  can  be  created  by  pressing  the  New  button.  (DO  NOT  CREATE 
A  NEW  SESSION  BEFORE  READING  THIS  GUIDE)  This  causes  the  New  session  popup 
window  to  appear  (see  figure  2).  In  the  Name  block,  fill  in  the  title  of  your  session.  For  the 
mandatory  Description,  be  sure  to  Ust  any  important  instructions  and  associated  web  pages. 
Do  not  finish  the  Description  with  a  URL  since  sd  will  append  a  period  and  interfere  with 
automatic  launch  of  Netscape/Mosaic.  Unused  Address,  Port  and  RTP  channel  ED  numbers 
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are  automatically  selected  by  session  directory  but  these  values  can  be  manually  changed  if 
desired.  The  Scope  or  time-to-live  range  {ttl)  determines  how  far  your  session  will  travel. 
For  example  a  ttl  of  16  would  just  go  out  across  the  NPS  campus  whereas  a  ttl  of  127  is 
world-wide.  DO  NOT  USE  TTL- 127  WITHOUT  FIRST  GETTING  CONSENSUS  WITH 
REM-CONF@ES.NET  MAIL  LIST.  The  Lifetime  block  is  where  you  determine  how  long 
session  directory  will  armoimce  your  session.  Also,  other  media  such  as  Audio,  Video  and 
Whiteboard  can  be  associated  with  a  session.  It  is  important  to  create  new  sessions  without 
error  since  editing  a  current  session  can  create  duphcates  instead  of  replacements. 

The  Edit  button  allows  you  to  make  changes  in  your  session.  The  Delete  button  will 
remove  your  session  and  Quit  will  exit  sd. 

The  software  for  session  directory  was  written  at  LBL  by  Van  Jacobson  and  is 
available  from  ftp://ftp.ee.lbl.gov:/conferencing/sd/ (^andlsy). 

2.  Network  Video  fnvl  tool:  Used  to  transmit  and  receive  slow  frame  rate  video. 
When  a  session  that  involves  video  communications  is  selected  from  the  session  directory,  a 
control  panel  appears  (see  figure  3).  It  consists  of  a  menu  bar,  a  box  to  show  iconic  versions 
of  active  video  streams,  and  some  number  of  additional  panels,  nv  allows  you  to  specify 
various  options.  In  most  cases,  the  assigned  defaults  work  just  fine. 

(1)  Menu  Bar 

The  Info  menu  lets  you  see  the  version  of  nv  you  have.  The  Grabbers 
menu  lets  you  select  among  available  grabbers.  Grabbers  which  are  supported  but  not 
available  on  the  local  host  are  grayed  out.  The  Encodings  menu  lets  you  select  which  video 
encoding  to  use  when  transmitting.  The  Panels  menu  allows  you  to  toggle  on  and  oflF  the 
presence  of  each  additional  panel.  The  Conference  Info  panel  contains  conference  address 
information,  as  well  as  a  place  to  set  your  name.  Each  of  these  fields  may  be  edited  -  changes 
take  affect  when  <Retum>  is  pressed  in  a  field. 
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Figure  3.  «v  Tool 


(2)  Control  Panel  Options 

The  mavimiim  bandwidth  limit  is  1024  Kbps.  The  default  bandwidth 
is  128  Kbps.  Frame  rates  of  3-5  frames  per  second  are  typical  for  the  default  bandwidth  of 
128  Kbps.  Some  systems  will  support  higher  frame  rates  if  the  bandwidth  is  raised  or  smaller 
images  are  sent. 

(3)  Video  Icon 

The  Video  icon  box  shows  a  small  video  image  with  a  name 
underneath  for  each  video  stream  it  receives.  Chcking  on  that  video  icon  will  display  a  larger 
video  image  for  that  source  (see  figure  4). 

Clicking  on  the  larger  video  image  will  display  an  extra  control  panel 
which  allows  you  to  adjust  the  Brightness  and  Contrast  of  the  image  (see  figure  5).  The 
brightness  and  contrast  parameters  range  from  0  to  100.  The  defaults  are  set  at  60  and  rarely 
need  adjustment.  The  display  size  for  incommg  video  windows  can  be  set  to  halh  normal,  or 
double  the  original  size. 
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Figure  4.  nv  Larger  Video  Icon 


The  control  panel  also  displays  the  source  address  of  the  sender,  the  video  format,  the 
incoming  and  displayed  frame  rate,  the  incoming  bandwidth,  and  a  running  average  value  for 
network  loss.  Other  controls  include  a  set  of  size  buttons,  a  switch  to  view  the  video  as  either 
Grayscale  or  Color  (if  color  is  being  sent),  and  a  button  which  allows  you  to  Capture  the 
ciurent  image  into  a  new  window. 

(4)  To  Exit 

Any  window  may  be  deleted  by  pressing  <Ctrl-C>  or  <ESC>.  If  you 
delete  the  control  panel  window  in  this  fashion,  the  program  will  exit. 

The  software  for  nv  was  written  at  Xerox  PARC  by  Ron  Frederick  and  is  available 
from ftp://parcftp.xerox.com:/pub/net-research/nvbin-*.  (Handley) 
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Figure  5.  nv  Control  Panel 


3.  Visual  Audio  Tool  (vat)  version  2.4:  Used  for  audio  teleconferences.  When  a 
session  that  iuvolves  audio  conuaunications  is  selected  from  the  session  directory,  the  vat 
window  appears.  It  is  not  necessary  to  speak  in  order  to  participate  in  a  conference.  In  fact, 
the  noimal  etiquette  is  to  wait  until  the  speaker  has  finished  and  has  opened  questions  to  the 
floor  or  to  the  Internet,  before  speaking.  Using  vat  requires  a  certain  amount  of  prudence  to 
avoid  accidental  transmissions  during  conference  sessions.  The  vat  window  is  divided  into 
two  parts:  the  right  has  controls  for  the  local  audio  and  the  left  side  displays  the  user  names 
of  those  individuals  participating  in  the  current  session  (see  figure  6). 
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Figure  6.  vat  window 


The  audio  controls  consist  of  two  sliders  that  control  the  microphone  and  speaker. 
To  adjust  the  shders,  either  chck  at  the  desired  position  or  chck  and  drag  the  sUde  button  to 
the  desired  position.  Just  to  the  left  of  each  slider  is  a  VU  meter.  A  rule  of  thumb  is  to  adjust 
the  mike  and  speaker  gain  shders  so  the  peak  readings  on  the  meter  are  about  80%  of  full 
scale.  Audio  input  has  two  forms:  microphone  and  line-in  mode.  The  microphone  is  normally 
used  for  desktop  conferencing  while  the  line-in  mode  works  best  for  room  conferencing. 
Above  the  speaker  and  microphone  buttons  is  a  button  to  mute/unmute  either  the  mike  or 
speaker  which  will  mute  out  sound  when  depressed.  The  button  will  be  highhghted  when 
muting.  Chcking  on  the  microphone  icon  will  toggle  input  selection  to  the  next  auxihary  input 
jack.  Chcking  on  the  speaker  icon  is  an  alternate  way  to  mute.  It  is  usuaUy  a  good  idea  to 
practice  getting  your  audio  levels  right  with  someone  else  remote. 

The  left  side  of  the  vat  window,  which  hsts  every  site  currently  participating  in  the 
session,  will  always  hst  your  site  first.  The  participant  name  is  displayed  in  a  box  that  is 
highhghted  whenever  that  site  is  speaking  and  grayed-out  if  the  participant  is  no  longer 


connected.  This  usually  indicates  that  the  site  has  lost  connectivity  or  that  vat  has  been 
aborted  or  stopped. 

There  is  a  box  to  the  left  of  each  participant  name.  Chcking  on  the  box  puts  an  ‘x’ 
in  it  and  will  cause  audio  from  that  participant  to  be  discarded  instead  of  played  (for  example, 
this  might  be  used  to  suppress  a  site  that  is  _ _ _ 


generating  echoes).  A  small  black  box 
inside  each  box  indicates  people  who  have 
spoken  recently.  Names,  by  defaidt, 
appear  in  the  form  user@host,  but  can  be 
changed  by  the  user  from  within  the  vat 
menu.  At  the  bottom  of  the  vat  window 
are  four  more  buttons; 

(1)  Keep  Audio 

One  host  can  run  a 
number  of  vat  sessions.  However,  since 
most  workstations  have  only  one  set  of 
audio  hardware,  only  one  of  those  sessions 
will  be  able  to  access  the  microphone  and 
speaker.  If  you  press  the  Keep  Audio 
button,  the  audio  device  will  be  acquired 
by  that  session  and  the  session  that 
previously  held  the  audio  will  relinquish  it. 
The  active  session  will  have  the  Keep 
Audio  button  highlighted. 
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Figure  7.  vat  Menu 


(2)  Menu 

Clicking  on  the  menu  label  at  the  bottom  of  the  vat  window  will  cause 
a  panel  of  auxihary  controls  to  open  (see  figure  7).  In  general  preset  defaults  should  be  used; 
however  you  have  the  option  of  adjusting  these  controls.  The  Audio  Tests  buttons  will 
generate  audio  test  tones  to  verify  software  and  your  audio  hardware  are  properly 
configured.  Loopback  lets  you  speak  into  the  microphone  and  hear  your  voice  locally.  Be 
careful  not  to  cause  feedback.  These  should  never  be  selected  during  a  conference.  No 
Silence  Suppress,  located  in  Output  Mode,  should  be  selected  for  noninteractive  sessions  at 
the  transmitting  she.  This  may  result  in  better  quality  audio  by  using  longer  playout  periods. 
Conference  mode,  located  in  Network  portion  of  the  Menu,  is  recommended  for  interactive 
sessions.  Lectiue  mode  should  be  chosen  for  noninteractrve  sessions.  The  switch  can  be 
made  at  any  time  and  takes  effect  immediately. 

There  are  two  type-in  boxes  at  the  bottom  of  the  Menu.  The  one  labeled 
Name  can  be  used  to  change  the  session  name  announced  to  other  shes.  The  one  labeled  Title 
can  be  used  to  change  the  title  of  your  session.  Go  ahead  and  be  creative!  Modifying  the  title 
is  an  excellent  way  to  pass  messages  during  an  audio  program  that  is  continuously  originating 
from  a  single  source.  The  Key  button  can  be  used  to  specify  an  encryption  key.  Since  vat 
conversations  are  typically  conducted  over  open  IP  networks  there  is  no  way  to  prevent 
eavesdropping,  particularly  for  multicast  conferences.  To  add  some  measure  of  privacy,  vat 
allows  the  audio  packet  streams  to  be  DES  encrypted.  The  Efismiss  button  will  return  you 
back  to  the  main  vat  window. 

(3)  Help.  This  button  provides  more  detailed  information  about  vat. 

(4)  Quit.  Selecting  this  button  will  end  the  vat  session. 

The  vat  software  was  written  by  Van  Jacobson  and  Steve  McCanne  of  LBL,  with 
contributed  effort  from  others,  and  is  available  from  ftp://ftp.ee.lbl.gov:/conferencing/vat/ 
(Handley). 
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4.  Video  Conference  (v/c):  vie  is  an  experimental  video  conferencing  tool  for 
transmitting  video  over  an  IP  Multicast  network.  The  main  vie  window  provides  an 
abbreviated  summary  of  all  sources  that  are  actively  transmitting  video  to  the  conference 
address  (see  figure  8).  If  no  one  is  transmitting  video  to  the  session,  the  text  ‘No  Network 
Sources’  will  be  displayed. 

Cheking  on  the  Menu  button  in  the  lower  right  hand  comer  of  the  main  vie  window 
will  bring  up  vie  menu  (see  figure  9),  which  is  composed  of  three  subpanels:  Transmission, 
Encoder,  and  Session. 


Figure  8.  vie  window 
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Figure  9.  vie  menu 


The  Transmission  subpanel  includes  a  Transmit  button  which  opens  the  video  capture 
device  and  begins  transmission.  The  Lock  button  is  designed  to  prevent  any  external  agents 
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from  automatically  initiating  or  terminating  transmission.  The  Release  button  will  terminate 
the  transmission  if  active  and  close  the  capture  device.  Adjacent  to  the  transmission  buttons 
are  Rate  Control  sliders.  The  bit  rate  is  limited  by  the  top  shder  while  the  frame  rate  is  limited 
by  the  bottom  shder.  The  frame  rate  shder  ranges  from  1  to  30  frames/sec,  while  the  bit-rate 
shder  ranges  from  10  to  3072  Kbps.  The  actual  capture  (and  encode)  rates  can  vary  within 
these  boimds  and  are  displayed  above  the  two  shders. 

The  Encoder  subpanel  contains  controls  for  selecting  the  coding  format,  video  image 
size,  coding  quality  level,  device  ports,  signal  type,  and  device.  Not  all  options  are  supported 
by  all  devices.  Formats  that  are  not  supported  by  the  underlying  device  (or  by  software 
compression)  are  grayed  out  and  disabled.  The  video  image  size  is  controlled  by  selecting 
generic  ‘small’,  ‘normal’  and  ‘large’  formats.  If  a  size  is  not  supported  by  the  underlying 
hardware,  the  corresponding  button  will  be  disabled.  The  Port  button  selects  among  the 
analog  input  jacks  to  the  capture  device  for  example,  a  VideoPix  has  two  composite  inputs 
and  an  S- Video  input.  The  Type  button  selects  the  analog  video  types,  which  is  one  of  auto, 
NTSC,  RAJL,  or  SECAM.  The  ‘auto’  setting  attempts  to  determine  the  signal  type  from  the 
actual  input. 

The  Session  subpanel' controls  conference  address  information,  some  type-in  boxes, 
and  other  session  controls.  The  first  line  of  the  panel  Usts  the  numeric  IP  address,  UDP  port 
of  the  conference,  the  RTP  source  identifier,  and  the  multicast  til.  The  type-in  box  labeled 
Name  can  be  used  to  change  the  RTP  session  name  announced  to  other  sites.  The  other  type- 
in  box  labeled  Key  contains  an  optional  session  key  for  encryption.  (Since  vie  conversations 
are  typically  conducted  over  open  IP  networks,  there  is  no  way  to  prevent  eavesdropping, 
particularly  for  multicast  conferences.  Below  the  type-in  boxes  are  switches  for  controlling 
session  behavior.  The  Mute  New  Sources  button,  when  selected,  causes  sources  that  transmit 
video  to  come  up  ‘muted.’ 

Along  the  bottom  of  the  control  menu  you  will  find  a  Tile  button.  This  is  a  pull-down 
menu  that  allows  you  to  specify  the  number  of  columns  to  use  for  displaying  the  thumbnail 
summaries  of  each  active  source.  The  default  is  single  column.  The  number  of  columns  can 
also  be  specified  by  typing  a  single  digit  into  the  main  window.  Also  along  the  bottom  is  a 
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Members  button  that  brings  up  a  top  level  window  with  a  scrollable  list  of  all  the  participants 
in  the  session.  This  hst  includes  participants  that  are  not  actively  sending  video.  The  Dismiss 
button  win  close  the  menu. 

Once  you  have  made  all  your  selections  in  the  menu  and  are  ready  to  send,  cUck  the 
Transmit  button.  A  small  video  image  will  appear  in  the  vie  main  window  (see  figure  10). 
If  other  participants  decide  to  transmit  over  the  same  session,  their  video  images  will  appear 
in  the  window  as  weh  For  each  video  source  the  vie  window  will  display  identification  text, 
some  bit  and  fi'ame  rate  statistics,  a  Mute  button,  a  Color  button,  a  Stats  button  as  well  as  the 
small  video  image. 

The  Mute  button,  when  selected,  causes  vie  to  ignore  video  fi-om  the  corresponding 
host.  In  general,  you  want  to  disable  any  site  you're  not  interested  in  to  reduce  processor 
load.  The  Color  button  controls  the  color  disposition  of  the  output.  When  enabled  (by 
de&uh),  video  is  displayed  in  color;  otherwise,  it  is  displayed  in  grayscale.  The  Stats  button 
brings  up  a  top  level  window  containing  network  and  video  coding  statistics  for  the 
corresponding  source.  These  statistics  are  updated  in  real-time  once  per  second. 


Figure  10.  vie  window  with  video  icon 
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Left-mouse  button  cUcking  on  a  video  image  will  open  a  larger  viewing  window  of 
the  participating  source  (see  figure  11).  Along  the  bottom  of  the  window  is  a  Size  button 
used  to  set  the  window  size  and  a  Dismiss  button  to  close  the  window.  The  Mode  button 
changes  the  switching  mode  of  the  window.  By  default,  the  switching  mode  is  “locked”, 
which  means  that  the  window  is  locked  onto  the  indicated  video  source.  In  “browse”  mode, 
you  can  cycle  through  the  participants  by  hand  using  the  ‘>’  and  keys. 
vie  was  developed  by  Van  Jacobson  and  Steve  McCanne  at  LBL. 


Figure  11.  vie  video  icon 


5.  Shared  whiteboard  (wb'i  tool:  Figure  12  is  a  picture  of  the  whiteboard  tool. 
Whiteboard  can  be  used  as  a  shared  drawing  surface  and  it  can  be  used  to  export  and  view 
small  PostScript  files.  Speakers  can  make  their  shdes  available  as  PostScript  files  during  a 
conference  session.  The  camera  can  be  directed  at  the  speaker  while  the  slides  are  viewed  via 
the  whiteboard  fecility.  Take  some  time  to  learn  this  tool.  At  first,  set  up  a  test  session  with 
a  ttl  of  1. 

The  software  was  written  at  LBL  by  Van  Jacobson  and  Steve  McCanne  and  is 
available  from ftp://ftp.ee. lbl.gov: /conferencmg/wb/*-wb.  tar. Z  (Handley) 
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Figure  12.  Whiteboard  tool  (w^)) 

D.  HARDWARE  REQUIREMENTS 

No  special  hardware  is  required  to  receive  video  on  the  MBone.  Decoding  and 
display  are  all  done  in  software  using  an  X-window  display.  The  data  rate  is  typically  25  Kbps 
to  128  Kbps.  Transmitting  video  requires  a  workstation  with  a  frame-capture  board  and 
camera,  typically  a  camcorder  with  a  video  output  or  buik-in  camera.  Several  different  boards 
are  supported,  including  Sun’s  Sun  Video,  SGI’s  IndigoVideo,  and  the  Sony  NEWS  frame 
capture  board. 

To  receive  audio,  a  machine  must  be  audio  equipped  such  as  the  SunSparclO  with  an 
audio  box,  some  Hewlett-Packard  workstations,  the  SGI  Indy  and  SGI  Indigo.  On  most 
architectures,  no  hardware  other  than  a  microphone  is  required  -  sound  EO  is  via  the  built-in 
audio  hardware. 

E.  OTHER  REQUIREMENTS 

1.  Good  lighting:  Given  a  choice  between  office  Ughting  and  a  desk  lamp,  the  lamp 
significantly  improves  image  quahty,  especially  in  otherwise  low  Ught  conditions  with 
inexpensive  cameras. 
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2.  Video  camera:  If  you  will  be  transmitting  video,  a  fixed  focus  camera  that  works 
well  in  your  particular  lighting  conditions  is  fine  for  the  desktop.  A  camcorder  is  more 
expensive,  but  performs  better  in  lower  hght  and  has  zoom  capabihty.  Once  again,  a  camera 
isn’t  required  to  receive  or  display  video. 

F.  POPULAR  EVENTS 

Many  things  are  broadcast  over  MBone,  including  NASA  Select  s  coverage  of  shuttle 
missions.  The  House  and  Senate  usually  broadcast  audio  sessions,  and  Radio  Free  Vat  is  a 
‘radio-station’  where  any  MBone  participant  can  sign  up  for  spots  to  play  music.  Scheduling 
events  is  very  important,  especially  if  they  are  to  be  transmitted  on  a  global  channel.  Events 
can  be  announced  by  sending  a  message  to  the  MBone  mailing  hst  called  rem-conf^es.net 
and  also  by  using  the  online  MBone  Global  Agenda  located  at 
http:/Avww.  cilea.  it/MBone/agenda.html. 

G.  MAP  OF  THE  MBONE 

A  small  map  of  the  MBone  can  be  found  at 

ftp://parcftp.xerox.com/pub/net-research/mbone-map-small.ps 

A  large  map  can  be  found  at 

ftp://parcftp.xerox.com/pub/net-research/mbone-map-big.ps 

H.  NETWORK  CONSroERATIONS 

Multicasting  is  bandwidth  efficient  as  one  packet  can  be  received  by  all  machines  on 
a  network.  For  example  one  audio  stream  received  by  one  workstation  uses  the  same 
bandwidth  as  the  same  stream  being  subscribed  to  by  15  workstations.  Another  good  feature 
of  the  MBone  is  that  the  life  of  a  session  can  be  limited,  for  example  a  broadcast  may  be  set 
to  last  30  minutes.  After  that  time  the  broadcast  ends  and  the  resources  are  recouped  for  new 
sessions. 

Another  good  feature  is  that  the  packets  may  be  limited  in  their  transmission  radius. 
There  isattl  (time  to  live)  setting  that  is  used  to  limit  how  fer  a  packet  might  go.  For  example 
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a  university  might  want  to  limit  a  transmission  from  a  general  student  machine  to  campus 
machines  only,  this  would  be  accomplished  by  a  ttl  setting  of  16.  This  can  happen  because  the 
ttl  field  is  decreased  each  time  the  packet  is  sent  through  an  mrouter.  This  limiting  abihty  is 
important  because  transmissions  such  as  video  can  use  much  of  the  resources  of  the 
connections  between  sites  on  the  Internet.  Audio  usually  consumes  32  or  up  to  64  Kbps  and 
default  video  twice  that  at  128  Kbps.  This  number  is  based  on  the  encoding  method  selected 
in  the  var/  window.  Video  multicasts  should  have  lower  ttl  setting  so  they  do  not  pass  through 
links  with  low  bandwidth. 

I.  DO’S&DON’TS 

There  are  no  formal  procedures  for  scheduling  the  use  of  the  MBone,  at  least  not  yet. 
Management  of  bandwidth  is  a  cooperative  effort  depending  on  the  good  behavior  of  the 
participants.  Using  the  MBone  without  any  regard  to  other  users  (i.e.  broadcasting  at  high 
amounts  of  bandwidth)  is  not  only  rude  but  can  bring  a  great  deal  of  embarrassment  to 
yourself  as  well  as  NFS.  Please  use  common  sense.  If  done  properly,  using  the  MBone  can 
be  fim. 

Typically,  discussion  of  the  use  of  the  MBone  happens  on  the  rem-conJ@fis.tiet 
mailing  fist.  To  subscribe  to  this  fist,  send  a  message  to  rem-conf-request@es.net.  Many 
events  are  announced  by  a  message  to  rem-conf.  The  following  are  some  gmdelines  to 
consider  when  planning  an  MBone  session: 

(1)  Realize  that  the  MBone  is  experimental  so  make  sure  you  understand  the 
fimdamentals  of  the  technology. 

(2)  Try  a  couple  of  test  sessions  at  a  t//  of  1 .  You  won’t  bother  anyone  with  this  and 
you’ll  learn  the  tools  and  can  even  use  a  higher  bandwidth  (say  256  Kbps). 

(3)  Read  the  man  pages  for  the  MBone  tools!  They  go  into  greater  detail. 

(4)  Announce  any  session  over  a  ttl  of  16  ahead  of  time  to  rem-conf@es.net 

(5)  Don’t  leave  your  Mute  button  off  while  in  vat.  No  one  else  will  be  able  to  talk 
to  you!  This  is  a  frequent  (and  embarrassing)  error  made  by  beginners. 
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(6)  Check  your  microphone  &  speaker  levels  in  vat.  They  should  be  at  approximately 
80%.  You  don’t  want  to  blast  out  remote  Usteners.  Get  confirmation  on  audio  levels  from 
remote  Usteners. 

(7)  If  broadcasting  a  noninteractive  session,  it  is  a  good  idea  to  get  status  reports 
fi-om  remote  sites.  Coordinate  volunteers  and  be  nice  to  them  -  they  are  doing  you  a  favor. 

(8)  Use  the  diagnostic  tools  that  come  with  the  MBone  tools.  Watch  packet  loss  as 
an  indicator  that  something  is  wrong. 

(9)  There  are  a  few  diagnostic  tools  like  tcpdump  that  are  designed  to  identify 
network  problems,  e.g.  bad  icmp  messages,  igmp  messages,  etc.  At  a  minimum  they  help  to 
see  if  packets  are  even  on  the  net.  Take  some  tune  to  learn  about  these  tools  and  use  them 
for  your  major  broadcasts. 

(10)  Conceivably  a  remote  user  may  somehow  gain  access  to  your  workstation.  The 
only  certain  way  to  prevent  unauthorized  eavesdropping  is  to  physically  cover  (disconnect) 
the  camera  and  physically  disconnect  the  microphone. 

J.  FURTHER  INFORMATION 

The  information  contained  in  this  guide  was  obtained  from  the  following  resources. 
For  a  more  comprehensive  understanding  of  the  MBone  and  associated  tools,  please  take  a 
look  at  these. 

1.  MBone  Provides  Audio  and  Video  Across  the  Internet,  IEEE  Computer 
magazine,  April  1994.  ftp://taurus.cs.nps.navy.mil/pub/i3la/mbone.html 

2.  Introductory  description  of  MBone  (draft)  from  MICE. 

3.  The  MBone  Information  Web.  http://www.eit.com/techinfo/mbone/mbone.html 

4.  Dan's  Quick  and  Dirty  Guide  to  Getting  Connected  to  the  MBone 

5.  Guide  to  MBone  etiquette,  http://www.eit.com/techinfo/mbone/etiquette.html 

6.  The  MBone  FAQ.  http://www.research.att.com/MBone-faq.html 

7.  Unix  Man  pages  on  vat,  nv  and  vie. 

8.  The  MBone  maihng  Ust  -  subscribe  to:  MBone-request@isi.edu 


57 


K.  ACCESSING  THE  MBone  TOOLS 

The  MBone  can  only  be  accessed  through  Unix  workstations  at  this  time.  Labs  at  the 
Naval  Postgraduate  School  that  currently  support  the  MBone  include: 

1.  IngersoU  Hall:  Visualization  Lab  (VisLab  room  148) 

Any  person  who  has  a  Computing  Services  Unix  account  and  has  received  MBone 
training  may  receive  execute  permissions  to  use  the  MBone  tools.  See  Larry  Frazier  (rm  In- 
1 13)  for  training  and  more  information. 

2.  Root  Hall:  Systems  Technology  Lab  (STL  room  204) 

Any  person  with  an  account  in  this  lab  automatically  has  execute  permissions  to  use 
the  MBone  tools.  See  Milena  Cochran  (room  204)  for  more  information. 

3.  Halligan  Hall:  Aero  Lab  (room  103D) 

Any  person  with  an  account  in  this  lab  automatically  has  execute  permissions  to  use 
the  MBone  tools.  See  Tony  CriceUi  (room  134)  for  more  information. 

4.  Melville  HaU:  Mechanical  Engineering  Lab  (room  138) 

Any  person  with  an  account  in  this  lab  automatically  has  execute  permissions  to  use 
the  MBone  tools.  The  MBone  tools  are  only  available  on  a  few  machines  in  this  lab.  See 
Dave  Marco  (room  138A)  for  more  information. 

5.  Spanagel  Hall:  Virtual  Reahty  Lab  (room  506) 

Any  person  who  has  an  account  in  this  lab  and  has  received  training  may  receive 
execute  permissions  to  use  the  MBone  tools.  See  Susan  Whalen  (room  525B)  or  RosaUe 
Johnson  (room  527B)  for  more  information. 

6.  Glasgow  Hall: 

The  MBone  tools  are  not  available  in  Glasgow. 

L.  LOGIN  PROCEDURES 
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For  informatioii  about  using  Unix  see  your  local  support  office  or  take  a  look  at  the 
Scientific  Visualization  Laboratory  User’s  Guide  (Chap  2,  sec  2).  It  can  be  found  online  at 
http://www.  tips.  navy,  mil/vislab/userdoc 

M.  POINTS  OF  CONTACT 

For  User  problems  please  check  with  one  of  the  following: 

1.  Ingersoll: 

-  Larry  Frazier  room  1 13  (x2671) 

-  Mike  McCann  room  102B  (x2752) 

-  Matthew  Koebbe  room  102A  (x3778) 

2.  Spanagel: 

-  Rosalie  Johnson  room  527B  (x3392) 

-  Susan  Whalen  room  525B  (x2967) 

3.  Root; 

-  Milena  Cochran  room  204  (xl  120) 

-  James  Schmidt  room  205B  (x3674) 

4.  Halligan: 

-  Tony  Cricelli  room  134  (x29 10) 

5.  Melville: 

-  Dave  Marco  room  138A  (x2809) 
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APPENDIX  B:  ACRONYMS 


ACM  Association  for  Computing  Machinery 

AI  Artificial  Intelligence 

AV  Audio  Visual 

CAI  Computer  Aided  Instruction 

CNET  Chief  of  Naval  Education  and  Training 

DFAS  Defense  Finance  and  Accounting  Service 

DoD  Department  of  Defense 

E-mail  Electronic  Mail 

FAQ  Frequently  Asked  Questions 

FDDI  Fiber  Distributed  Data  Interface 

FPS  Frames  Per  Second 

FTP  File  Transfer  Protocol 

GMT  Greenwich  Mean  Time 

ICMP  Internet  Control  Management  Protocol 

IETF  Internet  Engineering  Task  Force 

ERG  Information  Infrastructure  Research  Group 

BP  Internet  Protocol 

Kbps  Kilobits  per  second 

LAN  Local  Area  Network 

MBone  Multicast  Backbone 

Mbps  Megabits  per  second 

MICE  Multimedia  Integrated  Conferencing  for  Europe 

Mrouter  Multicast  Router 

NPS  Naval  Postgraduate  School 

NTSC  National  Television  Standards  Committee 

NV  Network  Video 

ONT  Office  of  Naval  Technology 
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PC  Personal  Computer 

SD  Session  Directory 

SGI  Silicon  Graphics  Incorporated 

SIGGRAPH  Special  Interest  Group  on  Graphics 

TAD  Temporary'  Active  Duty 

TCP  Transport  Control  Protocol 

TTL  time  to  live 

UDP  User  Datagram  Protocol 

URL  Uniform  Resource  Locator 

VCR  Video  Cassette  Recorder 

WAN  Wide  Area  Network 

WB  Whiteboard 

WWW  World  Wide  Web 

VAT  Visual  Audio  Tool 

VIC  Video  Conference 

VTC  Video  Teleconferencing 

VTT  Video  Teletraining 
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APPENDIX  C;  GLOSSARY 


Bandwidth.  A  measure  of  the  amount  of  data  that  can  be  transmitted  per  unit  of  time. 

The  greater  the  bandwidth,  the  higher  the  possible  data  transmission  rate. 

Broadcasting.  One  host  sends  to  all  hosts  on  the  same  subnet. 

CTJ-SeeMe.  A  video/audio  conferencing  application  that  runs  on  PCS  and  Macintosh 
computers. 

Data  Communications.  The  transmission  of  data  to  and  from  computers  and  components 
of  computer  systems. 

Data  Rate.  The  amount  of  information  that  can  be  transmitted  per  unit  of  time. 

Distance  Isaminp  Communication  between  an  instructor  and  student  via  some  form  of 
telecommunications. 

File  Tran.sfer  Protocol  tFTPV  The  standard  protocol  for  transferring  files  between 
machines  on  the  Internet. 

Information  Infrastructure  Research  Group. 

Internet.  The  global  collective  of  interconnected  computer  networks,  typically  those  that 
communicate  using  TCP/IP. 

Internet  Control  Message  Protocol  (ICMP). 

Internet  Protocol  IIPI.  Routes  data  packets  between  networks. 

Local  Area  Network  ILANl.  A  communications  network  in  which  all  of  the  components 
are  located  within  several  kilometers  of  each  other  and  which  uses  high  transmission 
speeds  -  generally  one  million  bits  per  second  or  higher. 

Multicast  Backbone.  A  virtual  network  that  provides  many-to-many  network  dehvery 
services  for  applications  such  as  videoconferencing  and  audio  where  several  hosts  need  to 
communicate  simultaneously. 

Multicasting.  The  abUity  of  an  application  to  send  a  smgle  message  to  the  network  and 
have  it  delivered  to  multiple  recipients  at  possibly  different  locations. 
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Network.  Two  or  more  computers  connected  via  a  communications  medium,  together 
with  all  communications,  hardware,  and  software  components.  Alternatively,  a  host 
processor,  together  with  its  attached  terminals,  workstations,  and  communications 
equipment,  for  example,  transmission  media,  modems,  and  so  on. 

Network  Video  tool.  A  tool  used  to  transmit  and  receive  slow  fi'ame  rate  video. 

Session  Directory.  A  tool  used  to  manage  MBone  sessions. 

Shared  whiteboard  tool.  A  shared  white  board  drawing  surface  that  can  be  used  to  export 
and  view  postscript  files. 

Time  To  Live  (tth.  A  counter  used  to  limit  multicast  packet  lifetimes.  A  threshold  that  a 
multicast  datagram  needs  to  be  forwarded  onto  a  given  tiumel. 

Transport  Control  Protocol  (TCPY  Provides  end-to-end  delivery  services,  rehability  and 
error  control. 

Unicasting.  One  host  is  sending  to  another  specific  single  host. 

User  Datagram  Protocol  rUDPV  A  connectionless  transport  protocol  that  allows  users  to 
send  messages  without  connection  estabhshment  and  without  any  guarantee  of  delivery 
service  or  sequencing.  UDP  is  simply  a  user  interface  to  IP. 

Video  Conference.  An  experimental  video  conferencing  tool  for  transmitting  video  over 
an  IP  Multicast  network. 

Video  teleconferencing.  A  two-way  electronic  form  of  communications  that  permits  two 
or  more  people  in  different  locations  to  engage  in  face-to-face  audio  and  visual 
communication.  Meetings,  seminars,  and  conferences  are  conducted  as  if  aU  participants 
are  in  the  same  room 

Video  teletraining  The  use  of  teleconferencing  point-to-point  or  multi-point  to  provide 
interactive  remote  site  training. 

Visual  Audio  Tool.  A  tool  used  for  audio  teleconferences. 

World  Wide  Web.  The  initiative  to  create  a  universal,  hypermedia-based  method  of  access 
to  information.  It  is  also  a  chent-server  based  service  that  runs  over  the  Internet.  Also 
called  webspace  in  another  sense. 
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